My first custom entity in Common Data Service

I still remember when I created my very first custom entity in CDS. It was back in 2007. I can’t recall any longer what the specific name of the entity was, but we were in the process of modeling our product and service lines into Microsoft CRM 3.0. The standard functionality for sales, service and marketing were already being used in different parts of the organization and now we needed to see if we could cover an even bigger share of our digital business processes with this low-code application development platform.

Wait, what year was that again? Did you mean 2017? CDS is a fairly new service from Microsoft, isn’t it?

There’s no typo in the year. Much of the technical foundation that you would use today for building a business application on top of Microsoft Power Platform existed already 13 years ago. Even longer, in fact. The technology for building a no-code web app with a custom data model consisting of entities, attributes, views, forms and sitemap has been around from the year 2005 already. Back then we called it XRM, whereas today we talk about CDS and Power Apps.

When I did the keynote presentation for the Finnish MS Tech Summit 2018 for a Microsoft partner architect audience, I used this slide to kick off my talk on “Power Platform: Connecting The Microsoft Cloud”. For those who are interested on taking a walk down memory lane and see an actual live demo video from the year 2005 on how all this technology worked back then, feel free to dive into this LinkedIn post.

My purpose here is not just to reminisce on the good ol’ days, though. There’s an important lesson here that everyone who is thinking about choosing an application platform to build up their organization’s digital capabilities in the year 2020. Here it is:

Of course this doesn’t mean that you’d have just been sitting idle for the whole time and not paying any attention to your business app. First off, you would have done a couple of version updates for your on-premises servers in the previous decade. Then at some point you understood you’ll need to take the system to the public cloud and let Microsoft manage it for you. After getting there you perhaps realized that a lot of the administrative work involved in keeping the systems up & running were actually much less burdensome in the cloud, so the ROI of the migration should have made given you some peace of mind on knowing you’ve made the right choice.

It’s highly unlikely that your business requirements would have remained the same as they were 15 years ago. 2005 was pre-mobile (meaning pre-iPhone), pre-social, pre-cloud – in short, a prehistoric era from the perspective of business application technology. There would have surely been a lot of new capabilities needed around those core entities where you stored your data, the UI used for accessing them and the business logic controlling what can be done on it by whom. Luckily the platform around the app has been following that very same path all along, giving you new capabilities for mobile access, modern APIs, better analytics, no-code automation tools and so on.

Let’s think about an alternative path for a while: what if instead of using a platform from Microsoft, you purchased a piece of packaged software aimed at managing that particular type of business data? In short, “COTS” (Commercial Off The Shelf) software. You might have received fancier features right out of the box, then spent a bit more on getting the app integrated into your data sources and workflows. Once you got that work out of the way, it’s all good! Right? Well, that all depends on what the chose software vendor ended up doing for the next couple of decades and how their choices aligned with A) what the market needed (i.e. are they still in business with that product offering) and B) what you needed going forward. Chances are you would be using something completely different as a tool today to solve the same business problem you thought you solved 15 years ago already.

Another possibility would have been to develop the whole system from the ground up. You know, Real Software Development instead of trying to just click your way through configuration screens inside a box built by some third party. In addition to getting an app that works exactly the way you specified it to (and offers absolutely nothing beyond that), you would have also saved up on software licensing costs. After all, why pay for some premium service like Power Apps for each user when you can just buy a few server licenses – or pay for Azure capacity in the cloud era. Things may have looked pretty sweet in your TCO calculations if all you considered was the initial setting up of the system, not the cost of living with it from one year to another. Oh, and speaking of those version upgrades that you get for packaged applications or an application platform, they go by a different name in this track: software development projects.

In the real world there’s hardly ever a single right answer – unless you’re playing the lottery. Business applications will be built through various means and depending on the circumstances the best approach may well be subscribing to a packaged SaaS app, or building the solution with custom code and leveraging the latest PaaS & IaaS services. The decision between Buy vs. Build is however being increasingly challenged with the option to Buy AND Build: buy a platform and build your solutions on top of it. An Application Platform as a Service (aPaaS) like Power Platform is not about solving a specific business problem in the most cost effective way, rather it is all about giving your organization the tools & capabilities to solve your own problems in an agile manner with a sensible and predictable cost structure – now and in the years to come.

“It is difficult to make predictions, especially about the future.” This famous quote feels more timely than ever during the COVID-19 pandemic and all of the disruption it has caused and will continue to cause on organizations and individuals. The future is not a direct projection of the past, yet we should still strive to use our past experiences to gain perspective on what choices have lead us to where we are now. Looking at merely the immediate requirements in front of us and trying to solve them may not lead us to a better place. Instead of just buying new things we should be aiming to take ownership of our digital tools and thus become masters of our own destiny.

Returning to the original story of how I took my first steps as a citizen developer 13 years ago and moved from being a system administrator to an app maker, it would have been simply impossible to envision where that road would lead. The speed of development for business application technology in the Microsoft stack has been incredible, but I think the most amazing part still is the backward compatibility. Instead of reinventing all the wheels every few years, there are aspects in the architecture that have been carried forward and maintained throughout the journey towards Power Platform, for a good reason. These are often the elements that are of the highest value to the end users: the unique data models and business records of organizations that have made the decision to invest in this platform technology and manage their day-to-day processes with it.

No, it probably wasn’t the prettiest of entities, the one I created back in 2007. It’s the fact that I could still be using it today in my Power Apps – that’s the beautiful part of the platform story.