2020 became the year of #WFH (work from home) and for many organizations also the turning point when Microsoft Teams became the primary place where being “at work” happens. This is accelerating the evolution of Teams from being merely a communication tool that connects human beings into a foundational service layer for many types of business applications.

How the concept of Teams as a platform contrasts with Microsoft’s Power Platform suite of technology is something I’ve been thinking about a lot lately. In this post I’ll first reflect on the relatively short history of where Teams came from. I’ll then examine how the recent feature announcements are brining apps front & center in Teams. Finally, a few words on the possible future for Teams as part of Microsoft’s broader strategy.

The road that lead to Teams

Looking back ~10 years, the real-time communication & instant messaging tools from MS seemed to be going through an endless renaming cycle: from OCS to Lync to Skype for Business. The core feature set presented to the end user didn’t seem to evolve nearly as much as product branding did. On a broader level, the communication activities of information workers within an organization still typically took place within Outlook’s inbox, and different servers like SharePoint and Dynamics CRM all packed their own features for posting short messages to other users.

4 years ago, when the first images of what was then called “Skype Teams” started to leak out, we were already waiting for MS to create something a bit more ambitious than just another online meeting tool. Office Groups had began to emerge in various different places inside the MS Cloud, but they were primarily a technical construct with no sensible UX for everyday people to approach them. Even Dynamics CRM had it’s own solution that attempted to bring together the dicussion, calendars, notes, documents and team memberships from under an Office 365 Group associated with a record like account or opportunity:

I remember having many discussions with our CRM customers where I attempted to steer people away from deploying this Groups solution. Instead I wanted to encourage them to wait for something a bit more polished that I knew had to be on it’s way sooner or later.

At one point there was a clear & present danger of another “Yammer moment” taking place, as Microsoft was reportedly quite serious about their plans to acquire Slack. In retrospect it was a blessing for both parties that MS decided to keep investing in building their own product, instead of trying to retrofit an established service like Slack into their existing software offering.

I would argue that this “build over buy” strategy which Microsoft has since then followed across their business software stack has been a key success factor for BizApps in particular. It has enabled MS to move from merely chasing CRM competitors like Salesforce into redefining the business apps playing field with Power Platform. There’s a stark difference between acquiring companies and bundling them as “X Cloud” versus engineering your own software stack to act as a true platform.

Teams: the collaboration chapter

Initially the first version of the Microsoft Teams product that became generally available in Spring 2017 was pretty much focused on being three things:

  1. Replacement for Skype for Business
  2. Alternative to Slack
  3. UI layer for Office 365 Groups

From a business applications perspective there wasn’t all that much you could do to hook Teams up with Dynamics 365, until Fall 2018 when the previews for the first integrated features were launched. In particular the integrated file sharing experience that Teams offered seemed almost like the Holy Grail for many CRM professionals, offering to fix the glaring hole in the SharePoint integration story that lacked any security model synchronization. The roadmap image below presents the plans from 2 years ago on how Teams and Dynamics 365 were going to be integrated:

The last item on the roadmap has still not been delivered, which is the visibility of Teams conversations inside the Dynamics 365 record form. Why this hasn’t been a higher priority for MS to implement seems to me like a sign of how Microsoft Teams is nowadays positioned as the primary UI for all information work. MS probably would prefer if everything always started from inside Teams. You pin record tabs into channels, you show previews of records inside teams discussions, you interact with records via bot interfaces and so on. As long as Teams is that big umbrella under which all work takes place.

The lack of a deep 2-way integration does not therefore mean that investments aren’t being made into the products involved. It can simply be a reflection of the new vision that is being built, by aligning many existing services to form a whole that aims to be greater than the sum of its parts.

As an example, if you look at Microsoft’s task management story, you’ll see that features and data from across various apps like To Do, Planner and Outlook tasks / flagged emails are currently being collapsed into a central location that is the Tasks app for Teams. Tasks as a generic construct don’t necessarily need to be fully controlled by a single database, yet they very much need to be logically represented within “the hub for teamwork” that Teams is positioned as.

Going forward, when new apps appear into the MS cloud product portfolio and they need to offer task management features to users, the logical integration point to focus on would be Teams. For activity feed type of functionality the choice is even more clear for product development: choose to piggyback on Teams instead of inventing yet another stream of short messages.

Teams: the platform chapter

Moving beyond simply integrating Teams with products X, Y and Z, we’re now seeing the rise of a model where apps are built specifically to be used in Teams. This has of course been possible for a long time already, by developing custom web services and using the SDKs. Now there are many features coming up that will amplify the platform story around Teams on the no-code/low-code front specifically.

lists in teams1.png

Microsoft Lists app has been the first to reach GA and offers an ultra low barrier for users to process data in a single table through a configurable, readymade UI. When accessed via Teams, the list data gains one more special dimension: discussions to be had regarding a list item. This is pretty much the same as the usage pattern offered for a Dynamics 365 record with the integration mentioned earlier.

Underneath the new covers of MS Lists is the technology familiar from SharePoint lists. If we were to only examine the UI layer, there is actually a remarkable similarity to a popular no-code service called Airtable. So much that the accusations of MS simply copying the visuals and core features from this competitor don’t seem entirely unjustified.

Comparing these two offerings gives us some perspective on what exactly is the market position these tools are aiming to conquer. Simple lists themselves are not a particularly unique feature, rather it’s the team collaboration capabilities and ease of data sharing that turns these tables into what you’d call an actual app. Incidentally, just this week Airtable announced they were building a full platform with apps offering JavaScript based extensibility, a marketplace for sharing apps, automations for executing business logic, and finally a sync service to transfer data across environments (“bases”).

Collaboration scenarios around semi-structured data like lists and Excel style tables can be seen as a gateway drug. They allow turning email or paper based manual processes into a quick first draft of what the digital process could be like. If there are indeed clear business benefits in automating the said process, the requirements for more complex app features will soon begin to emerge from the user base. Hence the collaboration platform should offer an obvious path to grow these pre-built app experiences into more advanced no-code/low-code apps.

Project Oakdale a.k.a bringing CDS to Teams

If Microsoft Lists is the equivalent of an Excel table within the Teams context, then Project Oakdale / “CDS Lite” could be though of as bringing SQL Server inside Teams. Now, obviously Microsoft has zero intent on actually replacing Excel nor SQL with features built into Teams. They only need to introduce those parts that make sense from a team collabocation perspective.

Microsoft Lists is a far cry from what a real Excel workbook can do, yet it can offer much more value in a collaboration scenarios that those lone .xlsx files ever could. Similarly, the version of CDS that will very soon be available for building Power Apps within Teams is nowhere near as powerful as the services powering enterprise CRM systems like Dynamics 365 (or the raw power offered by SQL). Still, the fact that it can be found from within every team and used by a much larger audience than what Power Apps citizen developer tools could hope to capture – those are the factors that can truly make CDS a mainstream service that most information workers in the Microsoft 365 cloud interact it.

The experience of defining the CDS data model in Project Oakdale will be very different from the path that Power Apps makers have gone through – let alone the XRM veterans. In fact, you could easily mistake the table design and row entry UX to be that of Microsoft Lists rather than CDS. This highlights a key aspect that not all Power Platform experts may yet have grasped: for MS this “CDS Lite” is not so much about deciding what premium features of the full Power Platform to give away for free to Teams subscibers – rather it’s about how to best simplify the enterprise CRM features of CDS into a new product that Teams users could adopt on their own.

This doesn’t mean that Microsoft Teams should be viewed only as a mechanism for MS to scale Power Platform to the masses, by “dumbing it down”. If the app platform story of Teams plays out like it ought to, there should also be clear benefits from it to enterprise business applications development.

Capabilities like messaging, notifications, task management, documents or group memberships are not something the Power Platform tools are very good at. For historical reasons there has been the need to build standalone features into XRM for these type of common requirements found in business application scenarios. For the future generations of apps being created, it’s easy to see the benefits of having these non-core capabilities offloaded onto a platform more suitable for managing them – meaning Teams.

It doesn’t really even matter if the feature set offered by Teams couldn’t cover all the deep business logic integration of native Dynamics 365 functionality. Ultimately it’s not about supporting the system-of-record legacy but rather encouraging the new low-code scenarios that will generate 100x more apps onto the platform.

Teams is the new Windows?

The concept of an operating system is something many of us may relate back to the origins of the Personal Computer era, even if OS’s of course have existed far longer than the IBM PC. Windows was the first runaway success in the OS space when it comes to both awareness and commercial results, shaping the fate of Microsoft for roughly three decades. Then along came the era of mobile computing and Android & iOS took over in the number of devices running them. MS could no longer hope to regain that position so they decided to take over a different layer in the computing space: the (business) app cloud.

Azure has been called “the world’s computer” and this does offer some perspective on how the computing concept has evolved since the PC days. Still, Azure is not something most people will ever interact with directly. To remain relevant in the decades to come, MS needs to have presence in the minds of the end users, too. Now that Windows has become merely an optional part of the modern computing stack, it would be pretty darn critical to gain a strong enough foothold on a level that’s above the traditional OS but still below the individual apps. A platform that spans across all the devices people in the business world are using.

Teams is now the closest thing that Microsoft has at its disposal to transform into an OS style fabric that connects a significant share of information workers globally. Nothing like the glory days of Windows, of course, but we should expect to see very conscious steps from MS to further the goal of Teams becoming more OS like. The place where the user interacts with a multitude of apps, share their work context with those apps, a “service bus” for the various apps to exchange data with one another, and finally a unified communications channel for notifications and messaging.

It’s still a long, long way to go for this type of shift to happen where the collaboration tools become the true center of gravity for the multitude of other apps and services that people use today in their #WFH offices. Personally, I can’t live with the limitations on multitasking that the MS Teams content embeds enforce upon the user and much prefer a collection of separate browser tabs to freely switch between. Nevertheless, it’s not an entirely crazy though that the resulting congnitive load for the user isn’t everyone’s ideal way of working. Which means organizations need to be looking for ways to optimize the employee experience via common information work hubs like Teams.

Dion Hinchcliffe has written an excellent analysis on Microsoft’s platform strategy with Teams, where he talks about seeing Teams as the operating system for work. While it may indeed be difficult to get the current owners of the collaboration tools in customer organizations to accept the business app side of Teams onto their plate (especially now with the #WFH boom and its unexpected requirements), the perspectives may change when the time is right from both the technical capabilities side as well as the organizational targets. In the same way as the MS CRM foundation evolved into a key element of the broader low-code application platform known today as Power Platform, the barriers between collaboration tools and business apps should not be perceived to be carved in stone.

Read More

ترك الرد

من فضلك ادخل تعليقك
من فضلك ادخل اسمك هنا