Today, I´d like to follow up on a story from one of my ideation workshops, where I was with a customer and the room was full of pro-developers that came in with their questions around Microsoft´s Power Platform and align Microsoft´s roadmap with their vision around integrating low-code development to achieve a tandem strategy for app development.
As I was starting to talk about the underdog they might have heard or read about, but not yet fully „adopted“, I highlighted a couple of features they would get out of the box from the Common Data Service, such as security, authentication or even relational database and audit log retention services.
Not surprisingly them coming from the Azure side and being familiar with Azure services, what caught their attention first though, was Azure Data Lake, Azure Dev Ops and Azure Synapse Analytics.
I kept introducing the Common Data Service, offering them way more services than just a simple relational database (which is what many are thinking of first, when Common Data Service is mentioned). After a short while thinking of all kind of services, it wasn´t a surprise them asking around the technical architecture of this „box“.
So we started talking about the facts, the Common Data Service running on Azure and extending with Azure services. We also discussed that just recently additionally to API first exposure, a TDS endpoint has been added as experimental preview which provides pro developers even more flexibility in their future app projects.
That way we could also address typical questions, such as why shouldn´t they use an Azure SQL Database or a Cosmos DB instead. Cause many people still don´t know that the underdog is using those services already out of box and provides low-coders to benefit from all without the need to configure them. Instead an easy to use and easy to maintain UI can be used, when interacting with the Common Data Service from an app makers perspective.
But all this wasn´t enough in terms of getting the underdog to be fully adopted as a new beloved child. Which immediately reminded me of a couple of social media discussions on Twitter, where a couple of my MVP friends and #PowerAddicts were discussing the pro´s and cons of using the Common Data Service. To many, still seen as a premium service and therefore a „to be avoided path“. I am sure my good friend Chris Huntingford (@TATTOOEDCRMGUY) won´t stop promoting the Common Data Service in favor of SharePoint.
Nevertheless, lucky me we were in an ideation workshop which brought up the opportunity to think of it differently – and those who know me or have seen my previous articles know that I am in favor of think differently. We therefore defined together a simple use-case scenario that is pretty much standard and might be well known by yours:
How about an existing app being in the need of enabling a user to search for a product and additionally show some details on the product journey?
When designing this scenario from a pro-dev perspective it is pretty simple task to think about structuring the data for the app and bring in additional services that would allow a simplified approach to achieve these goals.
Nevertheless, same as in real-life, a late-incoming breaking requirement for this app disrupted creation process (think of following an agile sprint design and -development process). But as I had Azure familiar developers around me, it was easy to define the Azure services needed to fulfill this additional requirement. If you might have recognized, all kind of Azure puzzle pieces are coming together – so the question was, are there any alternatives? Remember us being in an ideation workshop.
And yes, the alternative is to think of the app scenario like every (other) developer – thinking low-code. Cause with all the Azure services added for the app scenario there´re 10 services, where I need to understand
- their APIs
- their pricing models
- how they scale
- how they handle security
- how they work together
- how to operate them and additionally,
I have to think of an end to end telemetry and error handling that spans all those services. Therefore, I outlined the low-code approach [in the visual to the right], where instead we would use our underdog – the Common Data Service that allows us to easy design, build and maintain an app that also could be combined to other systems, services and SaaS platforms easily.
Guess how the ideation workshop ended? We talked about the tandem strategy in app development to combine pro-dev and low-code services and leverage the benefits from both worlds. The underdog became a first-class citizen of app development strategy and finally everyone understood, that it is way more, then a simple low-code relational database or just a premium service to be avoided.
For those, now asking if pricing was an issue. No, cause pricing or licensing shouldn´t be the only tour guide on your digital transformation (as I keep repetitive saying). Instead, getting to know options, evaluate and distinguish features or services should be on your top to-do list.
#NeverStopLearning – until then