About this Project
The proof-of-concept (POC) from Global Policies is a general design for both enterprise and datacenter networks. It caught the eye of another product team who wished to productize the POC, but this time, we were tasked to adopt the design for specifically for the enterprise network.
Challenges
While the design is focused on the enterprise network, it should be easily extensible to the datacenter domain. The challenge for us was to design an attractive policy application for enterprise customer, but still offer a logical extrapolation to the datacenter domain.
Figure 1 – Mockups from the client. The client is familiar with the design Global Policies POC and drew inspiration from there.
Insights
We recognized that there are roughly, two dichotomies for policy configuration: policies that have to do with users and policies that have nothing to do with users. For example, the administrator cares about whether user A is allowed to access user B or application C. The administrator also cares about the quality of service of application C, regardless of who is using it or not.
Access Policies are user-specific. Application policies, which have more to do with quality of service, are not.
The same observations made with the Global Policies proof-of-concept continued here:
Nobody has the mental capacity or will to look at all of the policies at once. There is little need to visualize or show all policies simultaneously.
Result
Similar to the proof-of-concept, the application has two major components: policy visualization and policy configuration.
The Dashboard shows the health and latest updates to the policies. In theory, policy changes are pushed to all devices instantaneously. But the reality is, given the diversity of the devices in the field, it is nearly impossible to make sure all devices are running the latest policies. In the case of troubleshooting, it becomes important to know which policy version which device is running.
/background(fff)/960x800.jpeg?auto=webp)
Figure 2 – Dashboard showing the health and latest policy updates.
Figure 3 – Animated sequencce showing the drill-down functionalities of the four top dashlets.
Access Policies are all about who can talk to whom via the network. The “talkers” could be users, applications, or servers.
Default policies are another reality and necessity in policy configuration. Whatever the policy administrator configures, are really just “exceptions” to the default policies. To avoid overwhelming the user, the design only shows the exception and hides the default policies until the policy administrator elects to see them.
/background(fff)/960x682.jpeg?auto=webp)
Figure 4 – Access Policies page. This is where the administrator configures who has access (or no access) to whom.
Figure 5 – Animated sequence showing how policies are edited. Clicking on the ‘Add Policies’ button reveals a panel where the administrator can add ‘allow’ or ‘deny’ policies for the selected group.
Neighborhoods define the model used to describe default policies. If things (users, applications, servers) are in the same neighborhood, then they can access each other by default. We designed a page to manage the membership of each neighborhood.
/background(fff)/960x682.jpeg?auto=webp)
Figure 6 – Neighborhoods page. Neighborhoods can be considered the “quick, default” policies as all groups in the same group automatically have access to each other.
Process
The following highlights the process the design team went through for this project:
Beyond this Project
We worked very closely with front-end and back-end engineering to productize this design. Because we know the client would eventually like to extend this application to the datacenter domain, we made sure that this was not a dead-end design by running the design through additional use cases.
Figure 7 – Additional mockups done to show that the design can be logically extended to support additional use cases like application policies (left) and policy templates (right).