Something that’s been popping up in our discussions quite often this past month is our chosen methods of organization for endpoints. As we get into the midst of designing our various endpoint pages, we dug into the discussion of how we would like to see the endpoints organized.
These discussions brought up a few questions for us.
- What is the best method of organization we can offer to businesses of different sizes, maturity, and disciplines?
- With our distinct focus in OS baselines, what style of organization makes the most sense to a user when the intention is to ensure that machines of a similar type also have similar baselines and are grouped accordingly?
- What kinds of systems should hold similar baselines?
Our old structure was loosely based on the AD OU system, but it was left largely unstructured beyond a few rules constraining group creation from becoming unmanageable. This was intended to allow businesses the maximum amount of freedom for setting up their organizational structure while ensuring that groups would be tied to consistent baselines.
In the original system, for two endpoints to be in the same group they had to have the same configuration set. If you had your groups organized by department, then all the endpoints in a department had to have identical baselines or close to it with exception groups.
Thinking about it further, assuming that the organization of endpoints is inherently tied to the endpoint’s baseline didn’t seem to be entirely sensible given the different levels of access that may be available to different individuals in a department. While we wanted to ensure there was some kind of structure to prevent the possibility of having hundreds of unique baselines, it didn’t necessarily mean that the baseline system had to be tied to the business’ organizational system.
Inspired by systems like Airtable’s tagging, we chose to separate out organizational structures from management groups as “labels”. By allowing users to organize endpoints however they wish through a freeform label system, endpoints could be organized based on the structure that the business wanted to adopt and free us to organize baselines through a separate method.
In the end, we decided that even with the separation of the labeling system, baseline setups could still vary greatly from organization to organization. As a result, we left the groups system in largely the same freeform format, but included a guided setup to provide directed suggestions for group organization based on user role. With the simple inclusion of the label system, it felt like a significant amount of flexibility was granted to the original group system as it no longer needed to serve dual purpose.
In our internal discussions, we strongly believed that baseline consistencies should be cross functional and based on the privileges of the users that utilize the system. As a result, our recommendations are strongly influenced by common user privileges. Providing this structure alongside a labeling system will hopefully allow users the flexibility to follow their internal structure while maintaining recommended baseline structures simultaneously.
In classic cyclical fashion, we rotated and debated through a whole host of potential options before ending back up where we started. In my next post, I think I’ll explore some of the other options and my thoughts on the advantages of each.
