About ISV’s, Being Stubborn and Flexibility

Let’s start with a short story.

The year is 2014 and the world was spinning as it did until March this year with mass tourism and in person events.

With the release of NAV 2013R2 and later 2015 our community was just starting to embrace the three tier concept and the Role Tailored Client. Nobody had heard of events or extensions. The economy is booming and everyone is busy not worrying about the future.

In that year I first did a small project for Datamasons to connect their EDI solution to Dynamics NAV using Web Services. Lateron I would do a similar project helping the folks of Dynamics TMS connecting their solution to NAV using an architecture that was as decoupled as possible and easy to upgrade.

When these ISV’s asked me to publicly endorse their solutions I told them that I would endorse the decoupled architecture and promote the idea of using best of bread solutions that interface with NAV rather than doing everything in NAV & C/Side.

This was not the first time I called the wrathfulness of an ISV in our ecosystem to turn against me but it was the first time it went quite big and ugly.

It happed at the NAVUG summit and it created some tention around the event for those involved.

The reason for writing this blog now and reflecting against something that happened five years ago is that this week several events happened that made me think about that NAVUG event several times.

If Your Only Tool Is a Hammer Then Every Problem Looks Like a Nail

I would repeat myself too much if I would start talking again about C/Side and the habbit of our community to use it as a single tool to solve all problems. It’s in-line with the ERP heritage from the late 1980’s and 1990’s when interfacing essentially was non existing, the internet had yet to be invented/adopted and infrastructure was hard to maintain and share.

The large ISV solutions that we have in our ecosystem are all born in the same era and back in the days these were founded by young people (most often or always guys) in their garage working long hours to establish their brand.

Today most of them are in their 50’s or early 60’s worrying more about their legacy than they do about the future.

Back then I was just a bit too young to join that party which leaves in in the middle with no legacy to worry about and an open mind into the future.

It’s a cloud-connected world

Today we live in a connected world in which it has never been easier to open your application and share data and processes accross platforms and geography.

Microsoft did a fantastic job with Azure on the one side as the leading cloud platform for serverless applications and Business Cental and the PowerPlatform/CDS as cloud ready frameworks to build system applications.

With Business Central it has never been easier to design an open architecture that allows you as an ISV to keep your solution small and manageable while allowing your partners to handle edge cases by subscribing to events or exchanging data using the API.

The Problem

For some reason, and I don’t really understand why, it looks like the larger ISV’s are not open to use this opportunity.

Many ISV’s have monolith applications that require “fob” files with thousands of objects to be inserted into your system. The reason for these monolith applications is the fact that they all try to solve all problems with the same software.

This is no longer nessesairy in the cloud world where you can break your application into multiple smaller components to start with, but you can also leverage the Azure stack to move parts of your application to Power Platform/CDS or even Cosmos, Docker, Microservice API’s etc.

The Solution

Time. That’s the only answer I can think of.

Given enough time we will see what happens and who winns.

If I had to place a bet I would avoid the majority of the horizonal solutions on AppSource that have a tight connection to AL.

Instead I would bet on those that have a decoupled architecture and allow their software to be seamlessly connected into anything that understands Odata Query Language and HTML5.

Comment List