3 considerations when managing diagram hierarchies (UPN)

3 CONSIDERATIONS WHEN MANAGING HIERARCHIES OF DIAGRAMS

UPN has been around over 15 years. Two key features of the standard are drill downs and attachments.  Therefore there are a number of considerations when managing diagrams them which we have identified based on 1,000 of client projects and millions of diagrams.

Spoiler alert: Drawing UPN with a single level diagramming tool is really, really hard

1. You are managing a hierarchy of diagrams and there are relationships between the diagrams.

• Diagram numbering so that you understand where they fit in the hierarchy: The traditional approach is the Level 1 diagram is 1. Level 2 diagram which is the child of the “shape” numbered 3 on the Level 1 diagram is 1.3. The Level 3 diagram from the 4th shape on the Level 2 diagram is 1.3.4. and so on.  You cannot rely on the titles of the diagrams because they may be different and more expansive than the text in the shape that is the parent, or gets changed.
• Hierarchical integrity when diagrams change or are deleted: If, for example, a Level 3 diagram is changed or deleted, you need to make sure that any changes are reflected in the Level 2 and all the Level 4 diagrams that were below the Level 3 diagram. The same is true if there are connections to other diagrams at the same level.
• Showing that a shape has a lower level diagram: Not every shape will have a child diagram. So it is important to be able to determine which shapes do have more detail and be able to easily navigate to the child diagram.
• Navigating through the diagrams: As you go down the structure you will have more and more diagrams. That is the power of math. If each diagram has just 4 drill downs, you will have 1 + 4 +16 + 64= 85 diagrams. Making it easy for stakeholders to navigate up and down the hierarchy, but also between diagrams at the same level is critically important to save time and prevent confusion.

2. The diagrams do not sit in isolation as there are relationships to other assets

• Linking to supporting information to support development and test; Any shape could link to notes, screenshots, specifications, requirements and user stories, Salesforce metadata- objects, integrations, automation, record type, and 3rd party systems and integration technologies.
• Links to other architecture assets; UPN business process diagrams are the operational view of the business processes which exist in parallel with the Architecture Diagrams which describe the systems perspective.

3. The diagrams are living documents that will evolve so they need to support collaboration and versioning

• Controlling access to the diagrams: To engage stakeholders the diagrams may be developed in live, remote workshops. The stakeholders need to be able to view but not edit the diagrams. Converting all the diagrams, or just the ones that changed, to PDF and distributing them is needlessly time consuming with the potential for stakeholders to be looking at out of date diagrams. The stakeholders should be able to access the diagrams in a portal with view-only rights, and either have a link that takes them to the correct diagram or they can easily drill down or navigate to the correct diagram.
• Collaborating and feedback: To drive continuous improvement stakeholders need to be able to provide feedback and drive discussions against any diagram. So, rather like a Slack channel or Chatter group embedded in every diagram, but the diagram authors should be able to aggregate the feedback and action it.
• Version control is at a diagram level: If a change of version is applied to a Level 3 diagram, do all the Level 4 diagrams have to change version? The short answer is no. Diagrams should be able to cycle in version independently, but you need to maintain integrity. Ideally there is a formal sign-off process and a history of changes tracked.

 

Did you know that Elements.cloud supports UPN.

Register for free and use the Playground to draw UPN diagrams for free for a single user

 

Photo by Mike Szczepanski on Unsplash