A Brief History of Collaboration and Governance

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:

1. Some power users figured out that if they had full control permissions then they could accomplish this themselves, without asking IT
2. Some IT departments mindlessly fulfilled any requests as they came in
3. 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.
4. 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.

1. FTP services enabled on the file server (or another server)
2. VPN access granted on case-by-case basis
3. Terminal services/Remote Desktop access granted
4. 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:

1. Collaboration just is messy–no matter what tools you use;
2. You have not been paying attention, and have ignored the level where collaboration actually happens (the level of the data);
3. 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.