Dynamo: An Enterprise Proposal

For the last few weeks I have been working on a Pragmatic Rollouts recipe and workflow for installing, customizing and updating Dynamo in a working office, and that process has led to some interesting discoveries and some thinking about how Dynamo can/should work as a production tool, rather than a neat toy. And, as one might expect, much of that thinking has related to what we have learned about using Revit on team based projects.

Over the past decade Revit Best Practice has come to broadly define three “tiers” of Project Team Role. I refer to these as Roles, not Users, because in my mind a user is a person, and a person can fill different roles depending on the situation.

In a Revit focused context, these tiers are:
Project Team: This is the role played by the largest number of users on most teams at any given time. In this role team members are focused on the work, using the tools as provided. Placing content, exporting to other formats, printing, etc. This is work that anyone can be tasked with doing.
Subject Experts: Subject Experts are the on team Power Users, with expertise in some area that not everyone shares. Modeling things like stairs or curtain walls is subject to required expertise. Modifying or creating project specific family content is subject to required expertise. And managing the project at a tools level as the Job Captain/Model Manager is subject to required expertise. Over time some members of the project team will have interest in and aptitude for certain subjects, and thus become Subject Experts, while continuing to spend most of their time working in a Project Team role.
Oversight/Overview: These are roles that extend beyond a particular project, require not just technical expertise (both with the discipline and the tools) but a big picture view of the business we are in, relationships with other professionals, and implementation & training implications. Content Creators and BIM/VDC Managers are Oversight roles, in that they define best practice , provide training and direction, interface with management, etc. Depending on firm structure Oversight roles may be exclusively Firm roles, or there may be a sub tier of Studio focused oversight, as well as firm wide oversight, when project types or particular client types require it. In multiple discipline firms there will also likely be discipline specific Oversight as well.
In most cases IT and Help Desk are Overview roles, at least in the context of discipline specific tools, in that they have a firm wide reach, but are not defining firm practice.

A thoroughly considered rollout of Revit, combined with a well implemented network infrastructure, provides a working environment where staff working in any of these roles can be effective, without being distracted by the needs of roles they are not currently focused on. Some of this is inherent in the tools; Content Creators, be they Project Team or Firm focused, work in the Family Editor, while the Project Team places content and works in the Properties Palette. Some of this is also cultural; experienced and well managed offices recognize projects with advanced stair or curtain wall needs and staff those projects with Subject Experts, rather than throwing available bodies at the problem.

It is my opinion that Dynamo will also follow this implementation pattern over time. However, as currently implemented, Dynamo is very much a tool for the Lone Wolf Power User. And outside of the Sole Proprietorship this way of working is long term detrimental; to the quality of the work and the viability of the business. Dynamo needs to be used in a team environment, and be tuned to that environment.

Translating these role tiers to Dynamo adds or refines the following Roles.
The Project Team: In this role team members are running vetted firm provided or project specific Graphs, without thought to the underlying nodes and packages required. They are provided with functioning and easily accessible Graphs and use them to complete project work, while being unaware and unconcerned with the underlying assets (nodes & packages) required to enable those graphs.

Project Team Visual Programming Experts: This role focuses on project specific needs that are not addressed by the Assets (graphs, nodes & packages) provided by the firm. They will find, modify or create assets as needed to address project needs, and coordinate with Oversight roles to evaluate those assets for inclusion in firm asset libraries.

Visual Programming Managers will evaluate available assets for suitability in the firm workflow, implement custom assets when needed, and coordinate with IT to ensure that vetted assets are made available to staff with minimal friction. Some firms will also have Studio/Discipline/Firm Visual Programming Experts, who address assets beyond project specific needs.
 

Based on this understanding of the use & management requirements, I see the functional & management requirements for Dynamo being as follows.

Dynamo Player

• Ability to (programmatically) seed Dynamo Player with most commonly used firm graphs, and remove example graphs when they aren’t appropriate for firm use.
• Ability to quickly find and load firm and project graphs as work needs dictate. Ideally this would be done using a File dialog that supports Windows 7 “file favorites/links” and Windows 10 “quick access” modes (reference)
• Ability to dynamically and programmatically add to the Dynamo Player list, so specific firm and project graphs can be made available with minimal friction.
• Dynamo Player integration with the Revit menu system, by way of menu items that run specified graphs in Dynamo Player. A menu of Firm Graphs that is programmatically managed, or automatically built by referencing a folder that contains graphs/graph bundles, would then allow the Dynamo Player UI to be exclusively for Project Graphs.
  Dynamo Player API, to allow Graphs to be run by 3rd party Asset Managers like Family Browser, as well as integration with the Revit Project Browser. The sooner Dynamo is “just another part of Revit” from a general staff perspective, the sooner it will see broad use.

Dynamo

• Ability to remove access to Dynamo proper for Project Team, leaving Dynamo Player as the sole Dynamo UI (including better integration of DP as outlined above). This could be addressed with a node in the Settings file that can not be accessed from the Dynamo or Dynamo Player UIs, much like some Revit.ini settings can be managed now. Even better would be a setting that defines a Group (local or domain) that “activates” Dynamo. Simply adding a user to the domain group triggers the change. This could provide an excellent proof of concept for similar behavior in Revit and other ADSK products, ALL of which could benefit from this kind of integration.
• Ability to block Automatic Updates of Dynamo (already provided via UpdateManagerConfig.xml)
• Ability to bundle node/package assets in a self contained graph, so that a complete functioning tool can be provided with no need to also manage dependencies.
• Improved settings functionality, to support firm customization. A UserDataCache version of the settings XML file similar to Revit would be a start, as well as environment variable expansion on load. (a variation on this is possible now with Pragmatic Rollouts).
• Improved upgrade functionality, that migrates settings from the previous version. Ideally now that Dynamo has moved past the beta stage, and side by side installs are no longer needed, the Dynamo program folders can be simplified. Rather than each build of Dynamo getting its own folder (1.0, 1.1, 1.2, etc.) a single folder holds the currently installed version. Installing a new build would archive the old Settings file, provide a new UDC settings file, import any appropriate settings from the archived version & not delete things like the update suppression file. First user launch of the new version would copy the UDC settings if no user settings present, but just add new settings nodes from UDC if the user already has a settings file, otherwise maintaining as many user settings as possible.

I would love to hear from anyone who is actively using Dynamo on team based projects. Does this outline fit with what you are doing, or need to be doing, or want to be doing? Or have you found that Dynamo as implemented can be integrated in a team environment with no issues or friction?