vRealize Operations Manager, as we know it today, comes packed with a vast array of built-in content. We have dashboards, views, reports, alerts, and a myriad of other content to help us paint the right picture for different types of users. Of this content, the most flexible, but daunting, can be dashboards. While it is admittingly easy to drag and drop some pictures of widgets on to a dashboards, a common pitfall is not fully understanding the capabilities of widgets and how to arrange them in to the most efficient workflows. In this article, we’re going to discuss some methodologies on defining workflows, choosing widgets and building interactions to create the most effective dashboards.
Define the Dashboard’s Objective
The beginning of any good dashboard begins with the definition of a business objective. The pursuit of this objective will give the dashboard purpose, and if it works well, value. Any dashboard may present new information or simply reorganize old information to offer new meaning, but the basic idea in authoring a dashboard is to work towards satisfying a defined business objective and generate more value for the audience than previously existed. Regardless of what the objective may be, the key is to be clear, concise, and realistic in what you expect from the dashboard.
As an example, we could state a business objective of needing a better understanding of workloads that are contributing to the disk I/O load on Datastore objects.
Plan a Workflow
Once a dashboard’s objective has been defined and the desired value is understood, we’ll begin to construct the dashboard’s workflow. The most straightforward way to construct a workflow is to understand the desired end value, put a box around it, and work in reverse to see how it can be consistently created. Every workflow should be easily repeatable for different users and not assume users have pre-existing information on how to arrive at the desired end value. Working in reverse from the desired end value, identify all of the steps that may be necessary in finding this end value. Once these reverse steps lead to a logical point where you could feasibly begin the workflow from scratch, you’ve identified your starting point for the workflow. Between the start and end of the workflow, all objects, metrics, relationships and product capabilities must be taken in to consideration. Discovering this initial workflow may have been accomplished using the different product UI elements, along with user intuition and memory, but the dashboard workflow will need to be accomplished using solely the dashboard’s capabilities. Ensure the workflow leverages these dashboard capabilities and minimizes the need for users to manually take steps outside the dashboard.
Continuing our previously stated example, we could say that we know for certain that we want to end the workflow with an understanding of each Datastore object and each of the elements that contribute to it’s disk I/O. We know that Virtual Machines are likely the primary contributors of this disk I/O workload, but we cannot be certain until we take a deeper look at the data.
Note: All workflows will rely on some understanding of the data and components being analyzed, with this example requiring VMware vSphere knowledge. When creating content that is intended to help others in analyzing and understanding data, it is crucial that the content author have a sufficient understanding of the subject matter at hand, without which the dashboard may ultimately emphasize the wrong elements in the wrong way and fail to meet the defined business objective.
Get to Know Your Data
At any given point, a dashboard will be limited by the type and quality of the data it has to work with within vRealize Operations Manager. Most workflows will require a particular set of objects and metrics, connected together with relationships to represent a cohesive chain of data that results in a repeatable workflow.
Before creating content for a dashboard, a thorough discovery of the environment’s data should be completed. This includes navigating vRealize Operations Manager to discover objects and metrics that relate to the business objective or use case, and how those elements are associated to one another using relationships. Some UI areas that may be helpful for this step are the “All Metrics” and “Environment Map” tabs. These tabs allow visual exploration of the environment in a manner than may identify objects, metrics and relationships to leverage in a dashboard.
In the absence of objects, metrics or relationships that may be necessary to meet the requirements of a workflow, several workarounds may be available. These may include the following:
- Add data sources or integrations to allow more data for analysis.
- When objects, metrics or relationships are absent, it may be necessary to further enrich the data within vRealize Operations Manager. This may be accomplished by adding additional Management Pack(s) or custom integration(s).
- Create Supermetrics that calculate derived values that may be missing from existing data.
- When metric values are absent, such as aggregate computations, a Supermetric may be used to create data points necessary for dashboard analysis.
- Leverage dashboard analysis widgets that provide analysis capabilities on-demand.
- Some dashboard widgets offer visual analysis capabilities that are not otherwise available in the product. One example of this is the Forensics widget, which offers a density and distribution histogram with the 75th, 90th and 95th percentiles of a dataset.
In our example, we want to discover the elements related to our Datastores and what may be contributed to their disk I/O workload. We would begin by selecting a Datastore in the left navigation pane, then opening the “All Metrics” tab in the right pane. Expand the top of the metrics graph area to include the Environment Map. From this point, different objects in the hierarchy can be selected, metrics graphed, and relationships identified.
Pick Your Widgets
Once the dashboard’s workflow is defined and data elements are understood, the process of selecting graphical elements may begin. Graphical elements in a dashboard are called widgets, with each widget offering a unique set of capabilities. These widgets are used to present information to the users, allow user interaction and analysis, and ultimately form the building blocks of the dashboard.
Each widget has a unique set of capabilities and strengths, but a universal concept is that widgets can be providers, receivers, or both. Providers often have the ability to ‘self-provide’ data, meaning they have a configuration option to independently populate data without the need of user interaction or initial population. These provider widgets will be the beginning every dashboard’s workflow. Receiving widgets will often by blank or unpopulated until data is passed to them via a widget interaction. These receiving widgets will typically be used for displaying data such as graphs and providing a point where deeper analysis can happen. Receiving widgets may also be providing widgets, offering the ability to continue workflows that had been passed to then via widget interactions.
The capabilities and nuances of each widget are outside the scope of this article, but the following widget capability matrix may be beneficial in understanding the high-level provider/receiver capabilities of each widget. This information will aid in the selection of widgets for a dashboard’s workflow.
vRealize Operations Manager 6.5 – Widget Capability Matrix
When selecting widgets and deciding how they may be populated, it is important to mind the aesthetics of the workflow and overall dashboard. A common mistake when creating a dashboard is to include as much detail as technically possible, using widgets to display buckets of data points and crafting Supermetrics to display every perceivable side of the data. Not only is this unnecessary, but it clutters the dashboard and becomes confusing for the audience. So for example, an author may opt to display ‘total’, ‘free’, ‘used’, ‘%-used’ and ‘%-free metrics’, whereas solely ‘%-used’ would be sufficient to identify an actionable situation.
As a rule of thumb, I recommend keeping the quantity of widgets on each dashboard below 6, occasionally using up to 10 for elaborate workflows with interactions. If data isn’t actionable or meaningful, it shouldn’t be displayed or emphasized. In short – less is more.
In our example, we’ll need the ability to navigate the associations between Datastores and Virtual Machines to accomplish the workflow needed to meet our objective. Given this requirement, we may opt to use the Object List widget, which has the ability to show “children of” and “parents of” objects that are passed to it through a widget interaction. This ability will allow us to pass a selected Datastore to an Object List and display all Virtual Machines that have a single north-bound relationship with that Datastore. In other words, this widget will let us select a Datastore and see exactly what Virtual Machines may be generating disk I/O load on it.
Plan Interactions
If we view widgets as the building blocks of as dashboard, the mortar that holds them together would be widget interactions. These interactions enable data to be passed between widgets and ultimately result in a more robust user experience than an otherwise static dashboard. While interactions aren’t appropriate for every objective or use case, they allow a deeper degree of widget analysis than would otherwise be possible with a static/hands-off dashboard.
When determining where and how interactions will be used, it is important to plan how the user will approach the dashboard and how their attention in directed to the beginning of a workflow. Placement of widgets influences the direction of user attention, with the top and top-left of a dashboard being a natural place to begin looking for a workflow. Depending on the dashboard’s audience, it may be beneficial to label widget titles as start points in the workflow, indicating “Select an object to begin”. Alternatively, a Text widget may be used to populate more detailed instructions on how to interact with and interpret a dashboard.
Interactions allow the selection of data within one widget and the automatic population of that data within one or more other widgets. These receiving widgets may show the object passed to it using that widget’s analysis capabilities, or it may show related objects (parent or child) that can be then selected and passed to yet another widget. This sequence of interaction is key to defining a successful workflow. There are no limits to how many interactions can be used, but at a certain point a dashboard will run out of browser real estate for widget analysis – mind the best practice of having at most six (6) widgets, with special workflows requiring up to ten (10). There is also an option to leverage dashboard interactions, which can pass data from a widget to a widget in a different dashboard where the workflow may continue. Select widgets also permit ‘multi-select interactions’, which allow the passing of multiple objects between widgets in the same interaction.
A major benefit to leveraging interactions is the reduction of redundant widgets and static information on dashboards. Where a static dashboard may need to be configured to display dozens of metrics to meet a use case requirement, an interactive dashboard may display a list of objects, allow an object selection, and subsequently display several key indicators for that object. The result is a dynamic and less clustered user experience, with users being empowered to view specific information instead of being overwhelmed with too much information.
While planning widget interactions for our example, we could opt to begin the workflow with an Object List that displays Datastore objects. When a Datastore is selected, a widget interaction passes objects to another Object List that is set to show “parents of” the object(s) passed to it. To continue our workflow towards our objective of understanding disk I/O on a Datastore, we may add columns to the receiving Object List to show Virtual Disk Aggregate Commands Per Second. The result is a two (2) widget workflow in a dashboard that uses a widget interaction to dynamically show all Virtual Machines on each selected Datastore, including an itemization of Virtual Machines along with their last disk I/O load. Dashboard complete!
Test Drive
Once a dashboard has taken form, the next step is taking it for a test drive to see if it actually meets the objectives you set out to address in the first place. It should be expected that iterative revisions will occur, largely because a dashboard’s perceived value is subjective and, as such, expectations and requirements may change over time.
Refinement and Maintenance
As dashboards are created and destroyed, a common theme that will prove true time and time again will be that dashboards built on dynamic structures and populations will have far more longevity than those built and maintained to statically populate data. Given this reality, Custom Groups with dynamic membership and other dynamic filtering mechanisms are the preferred means to populate providing widgets in dashboards.
Organization of content is also key to a healthy lifecycle of dashboards. Naming conventions of dashboards should be standardized within teams, as should the use of dashboard Tab Groups to organize content in to subject matter areas.
Distribution of content by means of Dashboard Sharing should be given some thought. vRealize Operations Manager allows dashboards to only have a single owning user at any given time, making content distribution controls of increased importance. A dashboard owner is the only user capable of editing that shared dashboard. The simplest way to address content management of this type is by nominating a service account to be the owner and repository of shared dashboards. In doing so, this creates a single place where dashboard can be edited and maintained for an organization.
Conclusion
With this basic methodology in authoring dashboards, any user can successfully create a dashboard that has value. This methodology was developed through my years of delivering vRealize Operations Manager in the field, and I hope that by reading this article you’ve gained a better understanding of dashboards and how to ensure they’ll be a success within your organizations.
Source: https://blogs.vmware.com/management/2017/03/vrops-methodology-to-authoring-dashboards.html