A Brief History of Collaboration and GovernanceAlex Fields
I have slowly been converting people to the “modern collaboration mindset” during the past couple of years through my op-ed style of writing. I think you can appreciate that changing minds through writing is something which rarely if ever happens in areas like politics, but it turns out this can still be done with more neutral topics like technology. Who knows? Maybe I could even change your mind.
Now while the modern admin embraces new tools and generally takes a more relaxed approach towards the idea of “Best Practices” (less dogma, more pragmatism–i.e. depends on the context), there are still some who are stuck in legacy thinking patterns which are tied to legacy technologies. So I thought a quick history lesson might help us to shake a few more people loose from the shackles of the past.
Who doesn’t love a little 2000’s era nostalgia?
In this era, IT administrators were the only people with the power to create new file shares from a central repository (server), and make them available to the masses (usually via a mapped network drive). Access to this location was controlled using an Access Control List, or ACL. If someone new needed access to this location, a request was sent in to IT, and that request was eventually fulfilled. The user would be added to the proper security groups, and everything worked beautifully.
But it did not take long for this structure to break down. First thing to note is that while users could not provision their own versions of “mapped drives,” they could create folders themselves in almost any location to which they had write access–their desktop, the company shared drive, the department share, their user drive, and so on. Every person engaged in this activity to some extent in every location, so we ended up with hundreds or even thousands of sub-folders, often many layers deep (because it was literally the only way of organizing or segmenting data).
Second came the requests to “break inheritance” and implement custom permissions to protect certain sub-folders from unauthorized or prying eyes. Sometimes this even included IT, and so this worked its way out in different ways in different organizations:
- Some power users figured out that if they had full control permissions then they could accomplish this themselves, without asking IT
- Some IT departments mindlessly fulfilled any requests as they came in
- Other departments said ‘Oh Hell No…’ to broken inheritance and ended up instead with more mapped drives than they had letters for–and often eventually caved to custom permissions anyway.
- And some users never even asked for inheritance breaks or special permissions (even if they probably should have); instead, they just placed random project folders in some random spot on the “Company-wide” share such as the Public (P:) drive–leaving non-public data exposed to the whole organization. But hey, at least information was difficult to find in general–so we had security by obscurity–great!
Then still more new requests came. Now we have to be able to share some of these files with outside people (either literally folks external to the org, or members of the org who were remotely attempting to access these files). Another slew of ideas was thrown up against the wall, and some of that even remains in play today.
- FTP services enabled on the file server (or another server)
- VPN access granted on case-by-case basis
- Terminal services/Remote Desktop access granted
- And of course, everyone’s favorite: Email
Every single one of these methods is based on what are now considered “legacy” constructs–artifacts from a bygone time. Sad, no? So here is what was really going on:
- A user screws around for a few minutes before finally getting connected to the FTP/VPN/Remote Desktop or whatever.
- They navigate through 30 levels of folders until they finally find and download the file they need to work with, or more likely, they just copy it to their own desktop, or email it to themselves
- They work on the file
- Next they email an edited copy over to their co-collaborator (which is probably easier than re-connecting to the whatever and uploading it again)
- The person on the receiving end saves a new copy of the document into whatever location they are most likely to find it in again–which is probably not the same as the original location
Now over time this got even worse for IT, because free services like DropBox effectively democratized easy file sharing. FTP quickly became the clunkiest thing ever, interest in remaining connected back to the corporate VPN faded quickly, and the rest is Shadow IT history.
So that story pretty much sums up every company I worked at or with from the early 2000’s up through 2013 or so. And it illustrates one more important point that I want to make in passing here: Collaboration sprawl is not a new thing since Teams was invented. It has been there all along.
The next evolution
Now we all know where the next chapter takes us–finally IT has caught up with the trends and migrated their organization into more modern structures in the cloud, such as Microsoft 365, which enables much easier collaboration and sharing, on any type of device, and with less back-and-forth emails and dozens of versions of files spread across multiple folders in your file system. VPN and Remote Desktop is not necessary in this world, at least for the purposes of file sharing–and thank goodness for that!
But guess what? Even though we have corporate-sponsored cloud apps now, we still have people working on umpteen different projects at a time, sometimes with similar groups of people but very often needing to connect with disparate groups. Sometimes these are folks inside the org and sometimes not. And because we don’t live in a completely homogenous world, that means you have people working not only in the corporate-sponsored Microsoft 365 environment, but other environments as well. DropBox, Gsuite, other apps, even other 365 tenants!
The beginning of the modern era
Slack figured this next step out before anyone else, and Teams is of course Microsoft’s answer to that phenomenon, and yes: both apps have been massively successful. The shift in this direction represented another fundamental change, which was again driven by outside forces: people needed a way to pull disparate sets of information coming from a variety of apps into one place and work with those things together as a team, to achieve particular outcomes. And they had to be able to do this quickly, effectively and often.
Sure, you could move from your OneNote, to your Skype contacts, to your SharePoint library, to your Trello board, to your PowerPoint, to an outside DropBox repository, and continue to circle around the mulberry bush like that all day long. But it was getting very difficult to do this across so many different projects and so many different apps, while working with so many different people. Every. Singe. Day.
Now, the thing about work today is that when a new idea pops up, folks just expect to be able to move on that idea. Today. Right now. This second. And that means we can’t be submitting requests into IT to share some files, or to invite some others to collaborate, or to provision a new container for organizing ideas and information.
Unlike the olden days, people don’t need to wait for IT. If they lack the power to do what they want, they run back to their own Shadow IT, or their business partner in that other org sends them a ShareFile link, or a Slack invite, or whatever. So if you don’t want that happening, then your absolute best bet is to make the safest choice the easiest choice (i.e. hosting the data on corporate sponsored infrastructure). And by the way, I shouldn’t have to use so many different apps to get one thing organized. That’s too much activation energy. All these things considered, the best practice (you read that right) is to allow the general information worker to create Groups and Teams (just like they could create folders in the olden days). With very rare exception.
Wait, What? Teams are like Folders? YES!
Hang in there, we are almost done! I just have to take a moment to highlight this last point: In both the old world and the new world IT has literally no clue what is happening either inside or outside the data repositories, and indeed, probably has no accurate inventory of their datasets to speak of.
You see, even back when you had those nice tight ACL’s and well-defined drive letters, all of which was easy to audit, the reality of what was happening “under the hood” is not something IT understood at all. They were well aware of the boundaries, such as the corporate firewall and the ACL’s on file servers, yet completely ignorant about the contents within those boundaries. What is the data actually “like”? Who really has access to what (especially difficult to know with hundreds of nested folders and broken inheritance, no)? Are some datasets being inappropriately stored in the wrong locations, or sometimes sent to the wrong people? Are there data locations outside of these that we have no idea about?
The reality is that almost no IT Professional I’ve ever consulted with can answer any of the above confidently and with a straight face. Then or now. And yet they freak out about the idea that end-users can just “willy-nilly” spin up a Team and invite people to collaborate on a whim. Get over it, people! You have always had the same exact risks, then and now. It has not changed in all this time, because:
- Collaboration just is messy–no matter what tools you use;
- You have not been paying attention, and have ignored the level where collaboration actually happens (the level of the data);
- Which adds up to the realization that, in all these years, you have not yet been practicing actual security, just pretend security.
But hey, don’t take this too personally; almost every IT person is in this same boat with you (and yes some exceptions do exist–I recognize that). But I would also like you to recognize that having 5,000 Teams or whatever is not a terrible thing; a bit messy yes–but everything is messy. In fact, I believe there is less risk here overall than where we were at in the previous era using more static collaboration containers.
Today we have exposed the true collaboration structure–all the hidden issues that were buried under umpteen layers of obscurity in your file system and behind Shadow IT have now been surfaced in the more “Group-centric” collaboration platforms like Teams. And that means we are finally now in a position where we can work to wrangle in and better understand the various groups as well as the data that is out there. This is a good thing, not a bad thing.
In my next post I will be sharing my thoughts on Sensitivity Labels–I believe that these are finally crystalizing as THE gold standard when it comes to Data Governance, and I believe they can address almost every single concern that people have with “container-based” or Microsoft 365 Group-based collaboration.
Great writeup and so true, particularly the point on collaboration being inherently ‘messy’. When you start collaborating, you general don’t know exactly what you want, who you’re going to involve, or the best structure. But the point is just start, and you’re allowed to start badly, because M365 has the tools in place to cover yourself.
Looking forward to your next one on Sensitivity Labels. I just wish they were compatible with more of the M365 service – Microsoft still recommend using retention labels for personal information that’ll need retrieved for reasons such as GDPR, which gets a bit confusing.
This is already improved, you can visit the security & compliance center to enable the capability for M365 services to read files encrypted with labels today. That way search, Delve, DLP, etc. all work. Still a few kinks though (e.g. co-authoring in Desktop apps).
Can’t wait for your write up. I’m looking at labels this Q3 and Q4. Good timing.
From my personal experience when users create a mess in their playground, they usually come to IT and ask to make sense of that. Now, if there is an internal culture that IT only provides tools and is not responsible for results of using these tools, then sure. On my previous job we had a file share with thousands of folders and levels. And we had a web based system of folders/permissions/owners, which was accessible to everyone. Granted, most users didn’t care about that list :) But there was also an internal audit unit which would came to IT and ask to prove who and why have access to this folder or that. We had no choice, but to have a system of requests. So, it could be not just IT clinging to legacy tools, but such restrictions coming from organizational policies, culture. I’m now in a much bigger company which is adopting Slack. Creation of channels is restricted. Although i would prefer to be able to quickly create a channel to work on something. Now have to resort to private group chats for that, which is not that convenient. And i’m guessing this came from compliance/legal departments and not originated in IT. Well, at least they are pushing to have as less private channels as possible, to break silos and enable more collaboration.
I think one of the big fears of leaving open creation policy is having too much clutter. The solution for that is simple: Groups expiration policy. The other fear is “I don’t know who has access to what data” which is simply not true–no more true than it was in the olden days on a file server, anyway. And with tools like Sensitivity labels at your finger tips now, you’re actually in a much better position than back then.
The problem is that “back then” we didn’t have an auditor roll through every so often asking about all of those items like some of us do today. :)
I’m dealing with Team sprawl, and I agree with the premise, I don’t care how many get created, but the problem for us is that people create multiple duplicate areas and then put data on each of them, then lose track of which is the item of record. Or they create a Team, assign permissions…then weeks/months later they semi-re-purpose the team, but don’t address the permissions and then we find out about various exposures from that, etc.
We have situations where 3 people will literally create 4 teams (AB, BC, AC, ABC), and then nobody remember where they read something and then just stop using teams.
We have so much sprawl (triple digit teams/quad digit channels for a 50’ish employee company) that people simply don’t use Teams for it’s “ideal” purpose, so now it’s just another email/sharepoint-like repository.
The only thing I will point out is that this same behavior happens in every type of environment–file server, Teams, Slack, DropBox, you name it. However, this is now 100% a behavioral problem. The tools now exist to ensure one source of truth per document, but people are largely still working as though they lived in the old world where information only existed in silos and they always had trouble finding it so they would keep their “own copy” in a place where they knew how to get to it. So the auditor issue is not any improved in any other environment, and not even if you limit the creation of Teams. It takes a level of digital literacy and organizational policy and governance to ensure that you end up with a cleaner environment–but I don’t believe that limiting group creation helps to achieve this (the sprawl just ends up spilling somewhere else, often outside of your view).
I thoroughly enjoyed reading this. Brought back both pleasant and unpleasant memories plus the realization that many orgs out there are still actually doing “pretend security”