Best Practices for Managing Map Scale

Some tips to enhance your software map that will improve navigation and understanding

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 the particular circumstances of your organisation. 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.

👍 Various application sizes, showing only larger apps when zoomed-out👍 Various application sizes, showing only larger apps when zoomed-out

👍 GOOD: Various application sizes, showing only larger apps when zoomed-out

👎 Same application sizes, all apps displayed when zoomed-out👎 Same application sizes, all apps displayed when zoomed-out

👎 BAD: Same application sizes, all apps displayed when 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.

👍 `Core` application tag with 3 child application tags👍 `Core` application tag with 3 child application tags

👍 GOOD: Core application tag with three child application tags

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 that have few or no interdependencies between them).

🚧

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').

Map creation form limiting map to applications that match `Application Filter`Map creation form limiting map to applications that match `Application Filter`

Map creation form limiting map to applications that match Application Filter

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.

Map creation form limiting map to applications tagged with tag group `Company A`Map creation form limiting map to applications tagged with tag group `Company A`

Map creation form limiting map to applications tagged with tag group Company A

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).
Metamap interface showing greyed out areas of the map not included in tag limitsMetamap interface showing greyed out areas of the map not included in tag limits

Metamap interface showing greyed out areas of the map not included in tag limits

  • 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 a publications' User Access to limit access to users of a member organization.
Publication settings screen, allowing access to everyone and including in a featured location on the `acme` landing pagePublication settings screen, allowing access to everyone and including in a featured location on the `acme` landing page

Publication settings screen, allowing access to everyone and including in a featured location on the acme landing page

👍

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.


Did this page help you?