Every organization has a strategy for managing data sets. Regardless of whether you explicitly state this strategy in a strategy document or not, your strategy depends on the decisions you make regarding the application of retention rules to the content of your business applications:
Each of these rival strategies has its advantages and disadvantages. Either one is a legitimate approach to records management.
This situation is made even more complex with the arrival of the cloud suites from technology giants Microsoft and Google. Each cloud suite is a combination of different applications for document management, collaboration, file sharing and messaging. Each cloud suite embodies an implicit records management strategy. The strategy can be seen in the retention functions that the suite is equipped with and how those functions relate to the applications in the suite. This opens up the possibility for an organization to explain some type of records management strategy, but provide a cloud suite that is informed of one of the competing strategies.
The way the Microsoft (Office) 365 cloud suite was set up shows that Microsoft has taken an "in-place" approach to records management. In the MS 365 Suite, no records management application is better than any other. The retention function is located in the Compliance Center outside of an application. Retention rules can be set in the Compliance Center and applied to any type of aggregation in any of the collaboration / document management / messaging / file sharing applications within the suite.
In the early years of Office 365, an organization may have been able to deploy the suite while continuing the strategy of moving all of the documents and messages needed as a record to a specific business application that is optimized for recording. Since the arrival of the MS teams, this doesn't seem to be possible anymore.
MS teams that are used as the primary collaboration system of an organization
The phenomenal increase in adoption of MS teams over the past two years has led to some fundamental changes in the record management strategies of those organizations that have adopted them as their primary collaboration application:
These two changes are related: The reason MS Teams are not as configurable as previous generations of collaboration systems is precisely because it is primarily a messaging system with content overflow Chat forwarded to individuals and teams and channels.
The impact of MS teams on an organization's record management strategy
Let's consider how the strategy for managing records of a typical large organization has evolved over the past two decades:
Here we have some elements of continuity, but also some important elements of discontinuity.
The main element of continuity is that the organization continues to encourage employees to contribute any document or message that is required as a record to a particular application. You still differentiate between:
The element of discontinuity lies in the Type of justification behind this distinction.
When the organization implemented an EDRM or SharePoint as a document management system for companies and asked the employees to move all documents and messages required as records into this system, they could argue that they were following a "records management by design" approach . They have tried to configure their corporate document management systems with a logical structure that reflects (as best they can) their business processes and with which they have tried to link appropriate retention and access rules.
You could justify the routine deletion of content in other applications by arguing that the by-design approach to records management relies on putting critical documents and messages in an application that has records management frameworks configured.
MS Teams and the Decline of Records Management by Design
For the past decade, SharePoint has dominated the enterprise document management system market and has dominated the market for systems that enable an organization to adopt a design-by-design approach to managing records.
SharePoint was on a journey. It started the decade as a stand-alone on-site document management system that end users would interact with directly. It ends the decade as part of a cloud suite. His role in this cloud suite is increasingly becoming that of a back-end system that offers MS teams document management functions.
An organization that has configured SharePoint as a corporate document management system with a carefully designed information architecture will find that the introduction of MS teams will override this structure and make it obsolete. Each new MS team is linked to a new SharePoint document library, which stores all documents published through its channels. In fact, this results in a parallel structure of document libraries that can compete with those previously set up in SharePoint for the same users.
At the time of writing, it does not appear possible to do records management with Microsoft Teams by design. The MS Teams information architecture is not suitable for this, and most organizations do not adopt teams.
Information architecture of MS teams
In MS teams, each team is a silo. There is no overarching structure for organizing the teams. Overarching structures are useful in any type of collaboration system not only to serve as a navigation structure for end users to find content, but also to put each collaboration area in context to support the ongoing management and storage of its content. A list of tenant teams is available in the Microsoft 365 Teams admin center. This list is only accessible to those who have administrator rights in the tenancy. Most organizations only give administrator rights to a very small number of people. The list includes an Information Governance / Records Management team that has little information about each team. It includes a basic listing of the team's name and number of channels, members, owners, and guests. (For a more detailed discussion of these issues, see this current IRMS podcast with Robert Bath.)
Leaving MS teams
In the past, companies typically used a phased rollout to deploy their corporate document management / collaboration system (EDRMS, SharePoint, etc.). Such systems would be introduced tranche by tranche to give the implementation team time to configure the specific areas of the system that each team in the tranche would use. This was necessary in order to close the gaps between the comprehensive framework for the organisation's brush information architecture and the specific work and documentation types of the area concerned.
Microsoft Teams is primarily a messaging system. It's a communication tool. It gives individuals the ability to send messages to other people through their chat client and share posts with their close colleagues through a team channel. The aim is to speed up communication and enable colleagues who are separated by remote work in space to be closely connected. Companies may have been happy to postpone the introduction of a document management system, but they are usually not happy to postpone the introduction of a messaging system as it would cut some employees off the flow of communication.
Teams have a design element. Decisions need to be made about what size is optimal for a team, how many different channels to set up on a team, and what channels to set up for. However, there are two major limitations to the scope of these design options.
The first limitation arises from the fact that the design decisions relate to team channels while most of the MS team traffic tends to go through team chat. There are no design decisions to make when implementing individual team chat clients.
The second limitation arises from the fact that however you design teams and team channels, you cannot overcome the fundamental architectural weakness of teams that every team has to be a silo. This is the main difference between SharePoint / EDRMS systems on the one hand and MS Teams on the other.
The access model in MS teams
SharePoint is a document management system. The access model for SharePoint sites and document libraries is flexible. You can silo the site / library if you wish by restricting access to a small number of people. However, you can also open access as far as possible. You can reduce the risk of full access by restricting the right to contribute, edit, and delete content to a small group while opening view access to a larger group.
MS Teams is primarily a messaging system with a document management component (provided by SharePoint) as a secondary element.
You can only view content on a specific team if you are a member of that team. Every team member has access to every channel on the team (except private channels) and to the team's document library. Any team member can post to channels and add and delete items from the document library. Therefore, expanding membership on a team is riskier than opening access to a document library in a SharePoint implementation, since anyone you make a member of the team has full editing and contributing rights on the team.
Another disadvantage to adding additional members to the team is that by making someone a member of the team, you expose the person to the flow of messages in and out of that team's channels. There's a catch-22 here. The more you expand your membership in a team, the more you direct message traffic from the team channels to the team chat. This is because the wider the membership, the greater the likelihood that a particular message will be uninteresting, irrelevant, or inappropriate to some members. By keeping the membership small, you can increase the percentage of traffic that flows through the channel but decrease the number of people who can access that traffic.
Microsoft teams and the concept of "retrospective governance"
The first time I heard the phrase "retrospective governance" was in chat on the sidelines of a recent IRMS webinar. An organization had a company-wide rollout of MS teams practically overnight in 2019, and the records manager said they tried the following year to implement "retrospective governance" by identifying which organizational unit each team belonged to and what it was for used, whether it was needed, which retention rule should apply to it. Numerous other participants reported similar experiences.
Retrospective governance isn't just available to Microsoft teams. For example, we can see retrospective governance in the use of analytics / eDiscovery tools to make and process decisions about older file shares (shared drives).
In the past, an organization may have chosen to apply retrospective governance to data in legacy applications and repositories, but such retrospective governance efforts were for the main focus of its application-centered records management strategy they were very marginalized and had their recording frameworks configured. With the advent of MS Teams, retrospective governance suddenly becomes the focus of a company's record management efforts. The rise of MS Teams means that within the MS 365 suite it is not possible to configure records management frameworks in one application so that that application record management takes precedence over other applications.
The strategy for managing data sets on site
Taking the existing records management approach, it is not currently possible to consistently move all critical business documents and messages into an application that is provided with a structure / schema that is optimized for records management. There are also many classes of business applications (including email systems and all other types of messaging systems) whose structure and scheme simply cannot be optimized for recording. As a result, a company's document management, messaging, file sharing, and collaboration applications should be treated as recording systems, even if the structure and metadata schema of most of these applications are not optimal for recording.
Unless and until it becomes possible to either a) move records consistently and comprehensively into an application optimized for recording, or b) configure each business application to have a structure and schema, that are optimal for recording We also need c) a viable strategy for managing records in applications whose structure and schema are not optimal for recording.
Dialogue with Microsoft about the implementation of the strategy for in-place records management
The records management profession has put a tremendous amount of work over the past 25 years into building a knowledge base for records management approaches that optimize a business application for recording. There is also a small amount of literature on the model in which you configure frameworks for records management in multiple, many, or all business applications. The profession has put much less work into defining best practices for the in-place records management approach. This is understandable as it wasn't our first choice of model. The lack is particularly noticeable in discussions with Microsoft about the management of data sets.
The in-place strategy included in the MS 365 Cloud Suite is to deploy applications without trying to ensure that the structure and schema of these applications are optimized for recording. Organizations apply retention rules to the aggregations that naturally occur in these various native applications (email accounts, SharePoint sites, One Drive accounts, team channels, team chat accounts, etc.) and request individuals (or tractors) to identify and tag any items that do so are exceptions to the retention rule for the aggregation in which they are housed.
We can point Microsoft to a truckload of best practice standards in records management, but almost everything has been written with an organization or vendor trying to design records management frameworks in a business application. There is little or no literature on the in-place strategy Microsoft is looking to implement in its cloud suite. We have nothing to measure Microsoft's execution of the in-place strategy in their suite, and nothing to guide organizations trying to use that strategy to implement the suite.
Filling the Void in Best Practices for Records Management
I am writing this on New Years Day. How about a collective New Year's resolution to build a knowledge base for the in-place strategy for records management? This should get us to ponder the key considerations when managing records across multiple document management, messaging, file sharing, and collaboration applications. Many of these structures and schemes are neither optimized nor can they be optimized for recording.
This should complement, but not replace, the existing knowledge base we have for the other two main strategies for managing data sets.
Laden …
