Jukka Niiranen

Tag: naming

  • Year 2020 in Microsoft Business Applications

    Year 2020 in Microsoft Business Applications

    Recently I had the privilege to make my sixth appearance in the CRM Rocks podcast run by Markus Erlandsson. Between our first session back in October 2013 and today, the world of CRM has certainly gone through a lot of interesting events. It’s amazing that out of those ~2600 days in between, there are now more days when a product named “Dynamics CRM” has NOT existed than it has.

    CRM of course still is very much a “thing” – it just isn’t the center of the Business Applications universe anymore. In our podcast with Markus we talked about the broader scope of what has happened with both the first-party Dynamics 365 applications as well as the Power Platform in the year 2020. Put on your headphones and listen to the CRM Rocks episode right here.

    The topics in the podcast also tie in nicely with another tradition of mine, which is writing these end of the year retrospectives about the top 3 topics that I’ve found to be most interesting or impactful for our ecosystem. Before we get started with the fourth edition in this series, let’s quickly check back on what themes I picked out last year at the end of 2019. They were: 1) low-code movement, 2) licensing confusion, 3) data story evolved.

    All fairly hot topics still today – which is of course the reason why I emphasized their importance one year ago. Now for 2020, this time I’ll keep you on the edge of your seat by introducing the top 3 in reverse order. Hold on tight, here we go!

    Nr. 3 from 2020: Renaming frenzy

    We all know that Microsoft loves updating not just their software but also the terminology used for referring to these products. CRM is of course a prime example of this. Microsoft’s isn’t always “following the money” by sticking to industry standard names, rather they prefer to reimagine the categories in which their technology can be used for solving new business problems.

    In 2020 we saw the iconic Office 365 brand get removed from the official vocabulary of Microsoft’s list of products available for purchase. Like with CRM, the actual technology and the customer use cases for the products didn’t see any major overhaul overnight. Previously there were SKUs in the price list branded Office 365 and Microsoft 365, which caused confusion for the customers, according to Microsoft’s own branding change announcement. Luckily now everything is crystal clear and no one will be talking about Office 365 in the year 2021 anymore. (Right?)

    While Offi… sorry, I mean Microsoft 365, is a mainstream product used by pretty much all customers in the MS Cloud, its rebranding in Spring 2020 turned out to be just a warm up for the real main event of 2020 that took place in July. I’m of course talking about the rise and fall of Microsoft Dataflex. In may have only lasted for exactly 3 weeks but the Dataflex era will surely be remembered as the crazy days of software branding.

    Luckily the Dataflex saga started in the middle of the year, which means we were able to catch the season finale before 2020 ended. The revised names of “Microsoft Dataverse” and “Microsoft Dataverse for Teams” were revealed in the GA launch of what used to be codename Project Oakdale. These names have persisted for six weeks already without changes, so they seem to be the real deal now.

    Following along the path travelled by CRM and XRM earlier, the three letter acronym of CDS is therefore now officially deprecated. What were perhaps more shocking casualties of the year 2020 were the terms “entity”, “field”, “record”, “option set” and “two options”. (I’m not counting “multi select option sets” in this list since everyone who’s had to deal with them probably hated them already, so good riddance.)

    As for how many adjustments there were to products in the Dynamics 365 family, I honestly can’t even tell. The fact that I needed to do a dedicated “why MS product naming is complex” type of a blog post to analyze the phenomena should be firm enough evidence that the renaming frenzy definitely was one of the top themes of 2020.

    Nr. 2 from 2020: Power Platform licensing complexity growth

    Measured by my own articles and the comments I’ve been hearing, there seems to be no end to how much headache the licensing of different Power Platform components is causing to people. Even though most of the last major changes to the licensing model were actually introduced already in 2019, I think the impact from them has only now started to hit home with a lot of the technical folks when trying to apply the new rules in real life scenarios.

    Earlier in the year there was a lot of fuss around the coming technical enforcement of access rights on the app module level. The immediate attention was of course on the arrival of Dynamics 365 Team Member licensing enforcement and the targeted app modules offered by MS while they would be blocking all other standard and custom apps. This was supposed to take place already on April 1st, but then COVID-19 came around and the deadline was pushed to January 31, 2021.

    We did still see a growing number of technical limitations implemented to keep customers in compliance with the licensing terms while using MS cloud services. The CDS Dataverse storage capacity in particular became a big practical blocker for customers wanting to leverage multiple Power Platform environments to some ALM practices for their low-code apps.

    While storage consumption is already enforced today, the big question on every developer’s mind (well, at least those who follow what the Power Platform community talks about) must be the API call limits. We’ve been getting a few bits & pieces of information here & there from MS about how they actually plan to keep track of the API quota for different operation types, but no definitive guide exists today. The eventual enforcement of these rules could potentially lead into future troubleshooting patterns where we could replace “DNS” with “licensing” in this popular meme:

    In the year 2020 I wrote in total 9 blog posts on the topic of Microsoft Business Applications licensing – including a 4 part series on the various sources of complexity in licensing. As for Microsoft, during the year 2020 they didn’t manage to launch the licensing consumption metrics dashboard that has been promised for Power Platform Admin Center ever since the October 2019 licensing model came into effect (on paper). With all these factors combined, licensing complexity in my eyes earns again a place in the 2020 Top 3 themes, just like it did in 2019. Let’s see if in 2021 things will settle down a bit and we’ll finally gain more confidence in understanding and managing the licensing costs of solutions built on top of Power Platform.

    Nr. 1 from 2020: Microsoft Teams as a platform

    There’s not a single doubt about what the year 2020 will be remembered for on a global scale. The total impact from the COVID-19 pandemic reaches far beyond the mere side effect that it had on us information workers, with everyone being forced to join the #WFH trend and getting used to all of our work being remote work. Still, that is the most immediately and easily observable part of what the virus did to us. As a result, for pretty much anyone working in the MS ecosystem, 2020 became the year of Teams, Teams and a whole lot more Teams.

    Working from home proved to information centric businesses that a surprisingly high percentage of those processes that weren’t fully digital before COVID-19 struck could actually be turned into such when no other option was given. While this will give a major boost to future digital transformation investments for sure, it also demonstrated how little new tech was actually need at the end of the day to make the typical business processes work without any sort of physical encounter. Already with our collaboration tools of 2020 and the low-code application platforms of 2020, many teams have learned to creatively solve their problems and get the job done. No massive multi-year initiatives and agile software development projects with big budgets were needed to reach “good enough for now”.

    In 2019 Microsoft started promoting Power Platform as “the platform for every developer” by addressing the pro developer audience on the benefits they could reap from adopting low-code tools as part of their app development toolkit. In 2020 it was time to address a much wider audience of power users, by promoting Microsoft Teams as a platform for the apps they could be creating for themselves, for their teams, or for their entire organization.

    Power Platform as a whole has managed to reach 1o million monthly users, based on the latest Microsoft FY21 Q1 earnings call. While that’s an impressive figure, it’s nothing compared to the 115 million daily active users that Microsoft Teams has. In my own analysis on this Teams as a Platform motion, I wrote about how Teams is gradually transforming into the next Windows:

    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.

    By bundling the basic Dataverse functionality inside Microsoft Teams both in technical and licensing terms, I’d say we’re seeing the low-code equivalent of what the Internet Explorer + Windows bundle represented back in the early days of the commercial usage of the web. It will be pretty tough for the competing vendors to find their way inside any existing corporate IT infrastructure on the same breadth as what Teams has already achieved.

    Teams of course was delivered there as part of the licensing payload of Office 365, which lead to competing workplace messaging platform Slack to file an antitrust complaint against Microsoft in the EU in July 2020. Later in December when the business app platform vendor Salesforce acquired Slack and announced it plans to use it to “create the operating system for the new way to work”, this kind of validated the strategy that MS had followed with Teams all along.

    The way I see it, Business Applications will increasingly be presented within the context of where the work actually gets done. They will become more targeted for the specific user groups and use cases that may well be unique to every organization. The complex ERP style systems of record will still exist behind the scenes, to orchestrate how work gets assigned, scheduled and invoiced. For the actual end user experience of interacting with these work processes, though, it will likely be closer to just using an app inside Teams than what is required operating the complex UIs of traditional enterprise applications. This is why the biggest theme of 2020 in Microsoft Business Applications has to be the concept of Teams as a key layer in the application platform story.

  • How naming works in the Power Platform universe

    How naming works in the Power Platform universe

    After the peculiar episode in July-August timeframe when Microsoft first tried to rebrand the Common Data Service and had to later cancel their plans, we’ve been eagerly awaiting to hear what they are actually going to call CDS from now on. Yesterday the Teams based features known as Project Oakdale finally went GA and now we know the answer. I won’t focus here on the actual features, but you can read my thoughts on them from the Forward Forever team’s blog:

    Hello Microsoft Dataverse

    The mapping of the old & new names is quite straightforward:

    • CDS = Dataverse
    • Project Oakdale a.k.a. “CDS Lite” = Dataverse for Teams

    Not all that different from their initial plans of using the name “Dataflex”, which didn’t go through since the owner of that trademark considered it to be an infringement and sued MS. Is the name “Dataverse” unique then? Not entirely, as there appears to be at least the Harvard Dataverse out there. Luckily it’s not as directly related to low-code application development platforms as the DataFlex that caused grief the last time.

    Just because there are other existing products out there in the IT space that use a particular word, this doesn’t mean new products would never appear in the market with the same name. As an example, last month a service called Microsoft Clarity was made Generally Available. Is “Clarity” a brand name that isn’t used by any other IT product? Of course it isn’t. The first thing that comes to my mind is Clarity PPM project & portfolio management software, but search engines will reveal many others. Heck even MS has acquired a BI software company called ProClarity back in 2006.

    That’s just how it goes in the real world. Coming up with a name that hasn’t ever been used before yet also means something is not an easy task. If instead of a Globally Unique ID you’re aiming for a product name that actually contains some hints about what the product does, then your choices will always be limited.

    Ah, the Choice / Choices in life…

    Which brings us to:

    Terminology updates inside the Dataverse

    Not only does the name of the technolgy itself change from CDS to Dataverse, there have been a number of terminology updates to the foundational concepts of the data platform:

    • Entity > Table
    • Field / Attribute > Column
    • Record > Row
    • Option set / Picklist > Choice
    • Multi select option set > Choices
    • Two options > Yes/No

    For a quick explanation about the scope of changes, see this short video by David Yack:

    I bet this is a bigger change for many of the professionals in Power Platform and Dynamics 365 area than the new Dataverse brand. We’ve been talking about entities ever since the birth of MS CRM and now all of a sudden the idea of “entities are much, MUCH more than a mere database table” should be replaced with “fine, they are tables”.

    Why are these changes necessary then? Largely for the same reasons why a more approachable name was needed for CDS: the target group for this technology is no longer the same – it is considerably broader. Microsoft doesn’t want the platform to be an exclusive club for those who thoroughly understand the business process management and data modeling techniques offered by their products, sometimes only after having gone through training courses and technical certifications. No, this needs to be something a power user that’s equipped with nothing more than a Microsoft Teams license can quickly figure out on their own.

    The path towards Teams as a platform brings more changes than just new names for familiar things. Previously the data model construction was a back-end task handled largely separately from configuring the app’s front-end. With Dataverse for Teams and later presumably in other UI’s, too, the interactive table editor supports both data model design and data entry all in one – much like a pre-built app á la Microsoft Lists does today. It doesn’t remove all the other functionality of entities in the underlying relationship management system, but it makes these optional at the start. You could just build a table like in Excel or Access, then later take it further as the app requirements become better defined.

    For those who have mastered the earlier XRM universe, the simplification of the terminology that was very specific and accurate to what the platform does may feel like a slap in the face. How can Microsoft tell us that we should pretend that it’s just a database table when we know the reality as well as the history? There isn’t much of an upside for these technical professionals in the new naming – at least if they don’t need to interact much with business users unfamiliar with the core concepts of CDS.

    We’ll get over it, though. Developers and even many no-code customizers will probably hold on to the entity/field terminology for quite a while – especially when on the API level everything the terms are not expected to change (at least for now). Having this dual reality of tables and entities isn’t going to present a huge cognitive challenge for those who’ve been with the platform for a longer time. The old content from pre-Dataverse era may cause confusion for the newbies, but we’ve already been through the merger of Power Apps & XRM a short while ago, which had a much more profound impact on the names of concepts in the platform. This too shall pass.

    While it may not be of much consolation, there’s one thing that we know won’t change: this changing of product and feature names isn’t ever going to stop.

    Why is this naming thing so hard in BizApps?

    I’m not going to write a four-part series on the product naming complexity just yet (like I did on the complexity of Power Platform licensing). Let’s try and keep it within this blog post for now. So, here are four reasons that make naming especially tricky in the context of Microsoft Business Applications are:

    1. Ambiguity
    2. Hierarchy of concepts
    3. Shifting product boundaries
    4. Marketing goals vs. market needs

    1. Ambiguity

    In a universe as broad as Power Platform, there can easily be overlap in naming elements of that platform that serve different purposes but really should have a fairly generic name. As an example, “a Power Apps portal” and “the Power Apps portal” are 2 different things. Excuse me, what?!? Yes, it’s all in the documentation. Power Apps portals are one of types of apps you can build, whereas the Power Apps portal is the place to create new tables and columns. People tend to refer to the latter one as the Maker Portal thanks to its URL, but it’s good to keep in mind that URLs in Power Platform do also change occasionally.

    Layout components

    This is why we now have Model-driven app forms which use the word “column” for both describing a field on a form as well as the number of adjacent containers within a tab or section. The original intentions for using easy and generic terms can sometimes create confusing results. If not in their native English language then most probably somewhere down the line when the terms get localized to a multitude of different languages.

    2. Hierarchy of concepts

    You won’t always have a clear view of what individual products and technologies will eventually be needed when pursuing a particular vision. Thinking about what CDS was called initially, it wasn’t a separate “thing”. It was embedded within the Common Data Model concept introduced in 2016. It took a year for this vision to evolve to a level where the actual data platform functionality operated by Microsoft was named Common Data Service and the earlier CDM term was dedicated to the idea of a shared schema across business apps from different vendors. It’s easy to see these should be 2 different things, but finding the right way to put them out there took a few iterations.

    Another example where things are a bit further already when a the need for redefining the terminology arises is Customer Insights. Microsoft has been shouting a lot about the booming demand for their Customer Data Platform solution (CDP, a generic term like CRM). Recently they’ve had to reshuffle the Insights deck of cards to ensure the gameplay works smoothly, so a hierarchy like this has been introduced:

    • Customer Insights: the top level concept of Microsoft’s CDP
      • Audience Insights: the features that were initially called Customer Insights, now referred to merely as a “capability” of CI.
      • Engagement Insights: announced originally as an independent product called Product Insights, now in preview as another capability of CI

    3. Shifting product boundaries

    Microsoft today excels in understanding the importance of their technology stack. You could also call it the platform approach in this context, but the point remains the same. Their products rarely get developed in isolation these days, rather there is (at least seemingly) a big push for combining elements of existing services to create new products. The problem is, though, that this game of connecting the dots isn’t ever really over.

    Survey feedback management was first brought into the Business Applications portfolio via acquiring an ISV product called Mojo Surveys that had been built on the XRM platform. After some rearchitecting and rebranding it was launched as Microsoft Voice of the Customer (VoC). The capabilities for the survey form design were quite lacking compared to the simplified UX in Microsoft Forms that had been developed internally on the Office 365 side of the house. Instead of retrofitting the form designer into VoC, MS decided to take CDS as the process and data management engine to give birth to a more structured feedback management tool, called Forms Pro. VoC was then deprecated and customers were asked to migrate to Forms Pro instead.

    In this process the technical capability of feedback management had hopped over the fence from the Dynamics side to the Office side. This was somewhat problematic from a business perspective, as well as causing confusion between the non-Pro and Pro usage of Forms. So, Microsoft ended up doing a further reimagining of EFM and rebranded Forms Pro to Dynamics 365 Customer Voice, bringing it back to the BizApps side where it started from.

    Returning to the previous example, before we had Dynamics 365 Customer Insights, the product names Microsoft used for referring to the same concept included “Cortana Intelligence Customer Insights” and “Azure Customer Insights”. The earlier Azure products that were offered in preview had to be scrapped and rebuilt as a Dynamics 365 product to finally see the GA milestone. Today it makes far more sense to have these type of packaged AI capabilities in the BizApps portfolio than in the Azure service catalog, but it wasn’t always obvious – especially back when Dynamics was just about CRM and ERP.

    4. Marketing goals vs. market needs

    Product marketing at Microsoft is in an endless pursuit of finding the best story that can sell customers a shiny new vision of what results they could achieve – if they choose the right technology from MS. Making a single purchase isn’t enough. You have to get the customers hooked on buying more from you, which leads to the invention of new things to sell. It’s easy to understand the incentives that lead to such actions, but they can sometimes end up irritating the customer who’s already made a purchase based on their own understanding of their needs.

    When Microsoft decided in 2016 that it would no longer sell a product called CRM, you could argue that their vision for tearing down the traditional CRM and ERP silos was logically a goal worth pursuing. The side effect from this product marketing goal was that when Microsoft took away the name “CRM”, they didn’t give anything new to replace it with. Reluctantly the Customer Engagement name was introduced a bit later, only to be quietly discontinued.

    The CRM systems that customers had deployed didn’t disappear anywhere of course. Companies offering professional services around them first struggled in migrating from Dynamics CRM consulting to Dynamics 365 CE consulting, and now they’re even more confused about what to call themselves.

    Microsoft’s branding changes aren’t ever exactly applauded in the partner or customer space, since renaming CDS to Dataflex to Dataverse will always cause extra work for them and give little in return. Removing an entire category like CRM has a far bigger impact than changing A to B. Redefining concepts and their boundaries is of course a very powerful way to stir things up and generate motion in the markets. I can’t say that I personally have any regrets on moving on from CRM, yet it’s easy to understand why not everyone is cheering when someone comes and says “what you’re doing is no longer a thing – time to reimagine everything!”