My intentional plan was to share a small blog about the Fall release of Business Central. Well – it turned out I had more to say than I imagined beforehand ;-).
I would like to focus on one point, where I’m not going to make myself really popular, as I notice quite a lot that people kind of disagree with me quite a lot :-). But that’s ok .. I don’t mind different opinions, as long I’m allowed to express mine ;-). Please take everything that follows as my opinion, and my opinion only.
Fall 2019 release
In Fall (probably October), we’ll have yet another major release of our beloved product Business Central. And Microsoft already shared their focus points in this slide:
Two points are totally not a surprise, I guess, as I announced that already:
- The fall release will not contain C/SIDE or C/AL!
- The fall release will not contain the Windows Client!
What I would like to do, is actually focus on the last bit. Extensions! There is going to be a strong focus for you to be able to do what you want, completely with Extensions. And even more, that last sentence:
“In the future, on-premises will follow the cloud rules”
What does that mean?
I understand this sentence can be understood in a lot of ways. And I wasn’t at Directions ASIA, so I wasn’t able to get the context of this – so I’m just going to make my own assumptions (disclaimer ;-)).
Just look at this twitter-thread from AJ and this one from Tobias. It kind of expresses some things that I will explain going forward – but at least, might give you an idea on how other people think about it as well.
Basically, I have a few assumptions that I’m going to assume is going to be the right assumptions. Assumptions² if you will .. :
- Microsoft wants all of us in the cloud (I think that’s an easy one)
- With Extensions only, not customizations.
- In order to do that, it needs to bring us as close as possible to be able to be as flexible as possible to do what we do today – with Extensions. I think that’s a very fair focus.
- Therefor – we should apply the same paradigms onprem, as we would for being “cloud ready”.
- Customizations are not “cloud ready”. So at some point (not in Fall), customizations are NOT going to be possible anymore – even on premise.
Again, just my assumptions.
We all like customizations, right? Well, to be honest, no. Some say it was the one thing that made NAV what it is today. Others say it implemented simplicity. I say: the simplicity to change the base app has kind of poisoned us. Sure, it’s easy on short term. But why-o-why are so many customers still running on old versions?
In anything I do with C/AL, NAV, … , I have had a strong focus of “upgradability”. Implementing with Hooks. Adopting Events. Adopting Extensions V1 .. all just to be able to upgrade. That’s my history. And a lot of my contributions were focused on that as well. Just take these blogposts into account:
- How I upgraded to Microsoft Dynamics NAV 2017
- The Hooks Pattern
- Hooks or events?
- Merge version lists
- To Hybrid or Not To Hybrid
I can tell you one thing: customizations do not facilitate upgrades in any decent way. From the moment you start customizing, you start creating upgrade-challenges. That’s the simple truth. One might not care, but we’re talking “cloud ready” here … and software with upgrade-challenges is all but “cloud ready”.
For a long time, Extensions has been the focus to solve that challenge. The feedback from some in the market though is a bit hesitant:
- “I can’t do everything with extensions”
- “I don’t have the events I need”
- “I can’t add document types”
- “I can’t …”
And you are all right, most probably. But in many (I won’t say all) occasions, those people make one crucial mistake. You try to do what you have been doing. That’s not how evolution works. With (r)evolution comes change. With change comes adaptability. You need to adapt. You need to change. And in terms of products, software (and yes, also customer customizations), that means: refactoring and reimplementation. Don’t act like the software you wrote 10 years ago, is still valid today. Cars are re-invented ever so long – but software needs to live forever? I don’t think so…
The focus in our company has been extensions for a long time. For sure, we are not able to do that for everything – and for sure, we are still doing customizations. More than I want to admit. Simply by the fact: our latest product release is still C/AL today.
But … there is a focus:
- No hybrid. What is hybrid? Why not? Well, I blogged about that here. So it’s either full C/AL or full AL. When we need to use our product today, it’s full C/AL. If not, it’s full AL. Luckily, we have quite some cases we can go the AL directions ;-).
- We are rebuilding (from scratch) our product this year. No migration, but a complete rewrite. Because in my opinion, it’s the only thing that really makes sense for us.
- When it’s AL, it’s Extensions only. So funky weird hybrid, no customized BaseApp (which wouldn’t be possible today anyway).
- When we go AL (for product or customers), we only apply cloud-ready architecture.
That’s our focus today .. so not in the future, but today. Our product is the only reason why we implement C/AL today. I’m not ashamed it not being converted yet. It’s a big-ass product, and we want to take the opportunity to rethink everything carefully. “Hurry” never ended up in decent software anyway ;-)). When the product is finished, the only reason we will be on C/AL in our company would be legacy customers, while all new customers will be full AL.
Let’s dive in the above points a little bit more.
Rebuilding, no migration
Well, I know there is a txt2al tool, and there are very valid cases to use it. You won’t hear any bad word about it from my mouth. It’s just – looking at our situation – having +1000 hooks (not events) (while in extensions, I don’t want to use hooks anymore), new design patterns to be applied with extensions, … and a lot more reasons, we decided to do a rewrite with the big advantage we won’t have any legacy-stuff to solve. We will focus on one thing though – that’s trying to make sure we can upgrade data.
The good thing on this approach is that we can completely revise all functionality in terms of begin “cloud-ready”, like:
- Remove all our .Net Interop
- Remove all our file-based integrations (or any kind of file-based automation)
- Focus on Service-based architecture (all funky stuff, provide (web) services for that – think “Azure Functions”)
Besides our product, we are currently into a 2-year development challenge for a customer, with heavily modified NAV, many integrations, .Net, file-based automation, .. and so on. An atypical heavy customized project. This project is being turned into a (set of) extension(s). I have no intention whatsoever to turn back to customizations, just because I think that my customers need to get what they expect: a way to upgrade, a way to be future-proof.
This project brings challenges for sure – but we’re getting there. I have full confidence we will be able to redo this heavy customized customer as a cloud-ready extension.
I already kind of explained what I mean with “cloud ready” architecture. Basically, it comes down to being able to run it in the cloud. In essence, we need to apply the cloud-rules. And in terms of “rules” in AL development, we think of “compiler” and “code analysers”, right?
Well, what we have been applying for all our extension-projects, is very simple this:
In app.json: target = extension
- So the compiler won’t enable anything that would not be able to run in the cloud as an extension, like .Net.
- In settings.json: enable code analyzer “PerTenantExtension”, so also my code is analysed as such.
Makes sense? May be not for you, but after 9 months of development, +800 objects, it still does for us :-). Thanks to this, we have found multiple unexpected parts that we needed to refactor. “Working with files ” and “working with .Net” being the most obvious ones.
BaseApp in AL
Big news – Microsoft was able to convert their C/AL to AL! It has been in the news for quite some time, but now you have it – next release (Fall 2019), this is the only way Microsoft will distribute its codebase. And that’s a major thing. Even more – you will be able to do customizations.
Taking into account that in the future, we will NOT be able to do customizations, me personally, I don’t give one flying rats ass (sorry for my French). Cool for Microsoft to have a good conversion tool – but I won’t use it – may be to convert a set of objects (like reports) to copy, but I promise you now: I will never convert our product to AL. Just because – in my opinion – there is only one way forward. And that’s Extensions.
If you would go down the route to migrate your product/customers/… to AL, just imagine. How do you manage:
- People are going to have to support those customers/products/databases
- Now they have C/AL or Extensions
- Then there is a 3rd scenario – a mix of default code (that you probably want to upgrade at some point), products and customizations in one codebase. In a new technology.
- Imagine 300 customers, some have pure C/AL, some hybrid, some baseapp+customizations, some pure Extensions.
- Good luck with that!
Maintenance / Upgradability:
- Congrats, you are on the new version
- But you haven’t progressed one singled bit.
- Upgrades is still a pain
- Maintenance is still a pain
- No way you will be able to easily migrate to the cloud
I’m a bit intentionally negative here – but I think you know what I mean when I say that I will never go down the route of customizing the BaseApp (as AL). Today, full C/AL or full AL Extensions. No other way for me. The only thing we need to do is make sure our product is finished (as Extensions) by the next release.
One of the things to be “cloud ready” is to not use .Net. I get feedback from people that sometimes there is just no other way. And probably they are right. But in many (if not most) cases, you can avoid .Net. Vjeko and me did a session on NAVTechDays last year, were one of the topics was exactly that. I can strongly advise to watch that section here:
So, there you have it – probably some of you think it’s time to unfollow me, unsubscribe from this blog, … . I strongly hope I didn’t offend anyone – this was merely an attempt to justify my opinion on things. Nothing more. I will never judge anyone for going down a route that I wouldn’t go to. Probably it would just mean that you are more organized (or more courageous) than me ;-).
Big thumbs up Eric! I for one, fully agree 👍👍
Thx, man 😉
Word said Waldo, I will still follow you.
We are following the same path as you, hopefully all our C/AL addons are converted into extension by fall release, it is not that difficult.
Thx! Nice to know!
Thumbs up, as always ;-).
I hope that Microsoft always will focus more on delivering more scripts/tools for supporting the Release Mgt. process instead of just pointing to standard tools (GIT, DevOps etc) and saying go luck to all partners. Also I am looking foward to a bad ass conversion tool from Microsoft that enables us out-of-the-box to move our existing data into extension data!
One thing is that the AL and extensions is the future (this is kind of the “easy” part for developers), but having the correct branching strategy for both add-ons and customer projects when you are dependent on a Microsoft Code base that changes every month and also putting all the peaces into a CI/CD pipeline, handling version numbering, breaking schema changes, automated test, releases for for internal test, customer test and prod is the biggest challange in my opinion.
Hopefully more of Freddys scripts will assist us partners.
Exactly, plus handling av dependencies!
Someone has to disagree, and apparently it has to be me 🙂
I think you are missing two important points.
1) According to the announcements back in Antwerp 2018 the new AL BaseApp will be divided in several smaller extensions. At the time they didn’t knew it it was going to be 5, 50 or even 500, but it is not just one huge BaseApp “extension”. This enables customers to only enable exactly the functionality they need. Each of these BaseAppGranules (in lack of better name) will be optional to use directly or if you wish to customize it into your own variant.
2) BaseAppGranules depending on other BaseAppGranueles will automatically depend on customized BaseAppGranule, as long as they comply to the interfaces.
Using this approach I think you’ll get the best of both the “old” and “new” worlds.
Thanks for your feedback – I totally don’t mind people to disagree if it’s done in a respectful way 😉
About point 1 – you are right. Microsoft WILL break the BaseApp up in multiple apps. “bottom up” if I remember correctly. But in that thought – you think it’s a good idea to start customizing it? I’m sure you understand there are going to be even more upgrade-challenges in that scenario as in the classic c/al story, no?
About point 2 – sure. Personally, I never worked with granules in the terms of “I never took them into account, nor depended on them”.
I guess I’m just trying to say headline could just as well be:
“In the future, the cloud will be just as customizable as traditional on-premise C/Side solutions”
I doubt all long time NAV customer will settle with the limitations of relying on only using new extensions. They will require the BaseApp (BaseApps?) to be customized to their need. Once we get the tools in place, I’m not sure it will be harder to keep updated than C/Side – on the contrary.
Microsoft have promised to publish BC on GitHub and we will be able to fork it to our customers. I think that will make it easier to keep updated than today.
That might have been a better headline, indeed :-).
I guess it depends on the customer. And also on the partner, finding the right design or solution in an extension context.. .
About the github-approach, I don’t know. We are ending up in having to manually text-merge again.. . With multiple conflicts, and no “somewhat intelligent” automerge like we had with PowerShell.. .
I would be most happy not having any upgrade-challenges anymore, only compatibility challenges … that’s find going forward ;-).
I hope and pray to God that the BC Base App will never be customizable and that we have to rely on solely extension the base app.
I truly believe this is the only good way moving forward.
Not being able to sell this to the customers is (pardon my French) bullsh*t.
It’s all about telling it to the customers in the right way. I know partners in i.e. the UK and Germany are all in selling hours and hours Development time upfront, but this is truly short-term thinking. It will not keep the customer happy in the long run.
Just my $0.02
It appears that much of the partner community is behind – much like the move to SQL Server (and to a lesser extent RTC) had many partners lagging. The forced move to AL and no more NAV sales is going to be a challenge for them.
Enjoy your blogs – especially since you promote the way forward.
‘Please take everything that follows as my opinion, and my opinion only.’
I disagree, it not your opinion only as its my opinion as well. Everything else is spot on.
Sorry .. ;-).
All positive developments aside.. (of which there are various)
And apart from the good blog and insight… (We keep following you 😉 )
2 words: Local resources….
Talking On-Premises (Following Cloud rules)
Removing file based integrations.
Should we tell all suppliers of our customers they should rebuild their own applications to stop using sFtp and start using web services? Because our modern ERP system doesn’t support file exchange out-of-the-box? We don’t live on an isolated island. (I know their are ways, but to call those progress.. Really?)
Our customers connect to industry scales which communicate via RS232. They also use serial port scanners to avoid field focus issues…
Page 1 – Document list -> Scan the document -> Open Page 2 -> Scan the item -> Selects the row -> Capture weights.
Page 1 opens the scanner port, determines if the input has to be relayed to page 2 (Item scan).
Page 2 opens the scale port and processes the weights. (While the port opened by page 1 is also active for item scans)
Not even talking about scales which have their own legacy software (COM) to be able to collect verified weights.
Now we can wrap those in C# controls, but in future?
Now you can integrate it as part of Dynamics NAV so the user has the full rich experience… In future?
I follow you when you say you should rethink your solution instead of copy-pasting it to AL.
And functionality wise it’s up to the partners to come up with up-to-date solutions.
But for some technologies there appear to be no valid (integrated) alternatives and to FORCE refactoring to lesser solutions or worse to a set of dependent / connected solutions. I can’t qualify that as progress.
But sorry to say, but aren’t these scenarios rather “exceptions” in the world of Business Central? Sure, we need to find solutions for that – and they might be worse, less efficient, slower, .. . But I can’t get myself to convince that a slower-working exception would mean there is no progress.. .
Just my 0,02€.
And obviously, if I would be in your shoes (which I’m not – I don’t have these usecases), I would probably totally be with you on this ;-).
I can’t speak for Business Central as a whole, but in the Food industry for instance a Scale is no exception. And integrating those in the Dynamics NAV flow is a must. Same would go for Business Central. Maybe not your regular SAAS customer, but it’s not me claiming “every customer should be able to work on SAAS”. In my personal opinion there is a different kind of customer with some extra needs, which you shouldn’t force to SAAS. If only not to be forced as MS to support every exception in SAAS.
They told everybody “We have to earn the right to deprecate the windows client”. If the web client is the only “Modern Client” not all use cases of the Windows Client are supported. It’s web browser safety which prohibits accessing local resources. Only a “new type” of “modern client” would solve this problem where you COULD grant access to local resources.
I’m very much with you on that.
Just thinking out loud on how to handle something like this, with the future in mind:
– create a completely empty, but generic app, that you depend on. Implement your methods in it. By default, it would call empty methods, but make them decouplable by the “var handled” pattern in combination with the “discovery event”.
– create dependent apps from the above one, and implement the higly onprem/dotnet/clientsideaddin/… code within that (and only that) extension. Douple the methods and call your methods like you’re used to. This way, your onprem/local resources are in this app only, and is completely removable;
– at some point, you could create a cloud-version of this (local web-api, calling it from BC). Decouple the same methods.
depending from the app you install, you will have the cloud-version of your solution, or the onprem version. Base-app wouldn’t change.
Just a thought…
You are so right, Waldo… I totally agree even if I’ve been a little scared for the move to Extensions. However, since I come from the .Net world, I feel that the move to new things like streams instead of files, events instead of hooks, and so on, it is all for the good of a sound base application. I would like, however, the base app to move to be more Objekt-like.
In the classic dev, I tried to always think “don’t touch the base”, but that was not always feasible in terms of time. It’s so easy to think “If I just add that in the base, it will make development easier” and I save time.
I have learned so many new ways to develop in Extensions that I find it harder and harder to think C/AL nowadays… But I have also stumbled across heavy bumps/walls
Navision was the hero when it was young and flexible.
Now it is going even more central, leaving the individual ‘vision’, and dropping all the stuff we got accustom(iz)ed to.
It is getting untouchable and unreachable.
There is no way back.
Going foward means change, chance and risk.
It was nice knowing you ‘Navision’ in your early stages.
We used to be wild and strong and developed our own visions and games with your tools.
Now we will have to (play) follow the leaders, the exodus, following the cloud not sure where it is taking us.
Is it milk and honey or was it desert.
I would like to pick up the “Random Passer´s” point.
As we all may remember; the idea of using computers used to be, to become more efficient and to be better than your competition.
I´m a Nav programmer for my company, so I have to accomplish what my colleagues need to have for productivity. Since we are dealing with food, we do use scales as well. And if you weigh hundreds or thousands of items per day, its not only that you need to transfer that decimal value, but also a reference number for every weighing process (mandatory by the german “Eichgesetz”). In short; there is no way to accomplish such things manually. On the other hand, you can use a scale whereever you want by making it “network ready”. Even a scale with a COM interface can be made “network ready” by using a COM Server device.
Follwing this example, my point is: “Network Readyness of Everthing – Hardware and local services”
Locally attached Hardware:
We used to have Document Scanners with a TWAIN interface – now we use Scan to folder or scan to a FTP Server
We bought new scales, which are “ethernet ready”
Photos of damaged deliveries are takes by a smartphone App, and uploaded through FTP
There shouldn´t be any local files anymore to be used, which is possible (unfortunately CU419 is a VERY BAD example how to do that)
Clicking a button, that creates an Excel sheet and attaches it to an Outlook body, where the user can add some text and click SEND (no idea yet)
When a salesperson picks up a call, the customer pops up in Nav. Something like this sould be a standard today. Currently we pick up the call event on the PC. Of cause there are theoretical solutions to pick up the calls on a Telephony server and issue events … within the BC Server …? At the moment we have no idea, how build such a new solution for that.
These are only a few examples for things, which must become “Network Ready”, because we desperately need them to retain productivity! Everybody is telling us, that we need to rethink such things, and we are not only willing but keen on doing so. However we don´t have a solution by now, and we haven´t met anyone, who has one.
1. Thank you Waldo, to make it crystal clear, where thing are herading to.
2. Microsoft is not wrong in general with their new direction for BC
3. We will have to be very creative on that, but in theory it should be possible to make anything netword ready (at least on premises)
Thank you very much for your insights, Michael!
……and how do you explain the need of going to the cloud to customers located in the middle of nowhere with unstable Internet connection? Quite easy to advise to do that from New York City, Amsterdam, or Toronto, is not it?
I just can’t understand why Brummel is the only person in the whole MVP list community expressing valid and ridiculously sobering concerns.
Other than that – good luck with migrating your customers to the cloud. Certainly, not the approach most of the NAV customers (dozens) I deal with are taking. And not the approach 95% of the existent NAV customers worldwide are planning to take in the nearest future.
Well .. cloud is something that needs to prove itself, sure – but I believe that indeed the market is moving towards it – and in my opinion, it’s better to have a solution when it’s there. We can’t keep denying…
That said – the post was more about how to develop – no matter it’s on cloud or onprem. As I stated, I think it’s better to apply “cloud-ready” software architecture, even when it’s on prem. Simply because it’s more stable, more robust, more secure, more reliable, more future proof, … .
And about EX-MVP “Mark Brummel”, well, it’s for damn sure we don’t share the same opinions … no secret there.
Thanks for your insights! I really appreciate it!
I think you’re doing amazing job. I never denied it, and, quite frankly – have been reading your blog for years. You’re one of the old NAV-dinosaurs (good meaning, saying it based on your many years of experience) who’s opinion values a lot for the community.
However, folks like Brummel or Stryk are replaced by many newcomers who’s MVP now (you refer to them many times in your blog, but I don’t want to go personal or reveal their names as it would be openly disrespectful to them) and keep posting nonsense about “development”, “AppSource” etc. in a “wow, great job Microsoft” manner…
NAV is not ONLY about development, but about implementation. More than half of these nowadays influential bloggers won’t be able to implement standard MRP on a project of 10+ users. Simply because NAV implementation is not about “AppSource” or “artificial intelligence” c$ap. It’s about functional knowledge.
That makes me sad that opinion and NAV values of old, “20+ years of implementation experience” folks like Brummel or Stryk aren’t heard, and instead – silenced by the glamorous nonsense posted for the last 2 years by expanded MVP group. And quality of the NAV MVP community decreased drastically for the last few years.
I can only speak for myself, Mike. But looking at the MVP community, I see lots of successful partners in there – IN the cloud, pursuing what Microsoft is pursuing. Successfully. I don’t have anything negative to say about the MVP’s. And by the way, Mark wasn’t replaced or pushed out by Microsoft – he got out himself (at least as far as I know – you’ll have to ask himself). I don’t know about Jörg, though.
Afaik, Microsoft always values opinions, good and bad. But that doesn’t mean they are not going to pursue their goals. I have given lots of critisism to Microsoft (I just try to not do that too publicly, because I don’t believe in (what I call) “social pressure” – that only works counter-productive), and from what I’ve seen is that they always take it into account, and do what they can to solve and make better.. . Most (if not all) of the roadmap is there because the community has asked for it .. .
Also, can we blaim Microsoft of pursuing the new market (they are by the way not abandoning OnPrem, just focussing on Cloud)? Resell customers they already sold isn’t growing anyone’s business, am I wrong? 😉
To be in the Cloud will still be a risk and a huge challange:
– Most of all due to the ISPs (at least for germany) – get redundant connections from several IPSs
– What, if MS has a longer downtime –> they won´t pay for our losses
– Cloud ist that “kind of cheap” where you´ll finally pay more than before, if you scale it to what you really need
– Lots of technical implementations need to be re-invented first. That needs tons of time and new skills
– I still see a severe conflict between GDPR and the US Cloud Act for Microsoft. But “which cloud”, if not Azure?
On the other hand …
Imagine a world where you get “Information at your fingertip, any time, any place”, as Bill Gates stated in the 90th. I know companies, that only use ChromeBooks anymore. Everthing they do, is in the browser. Imagine a world. where you don´t have to patch your Win10 every month again and again and again. OK – the employees of that company, I had the chance to talk to, were not really happy with that … at least not yet..
But all this will be a huge challenge. Take my thread about “Network-Readyness of everything”. Currently we do some research on Socket.IO. The idea is, to communicate from JS Socket.IO with a C# Socket.IO class through the localhost. On the other hand we are no professional developers, so it takes us a lot of time to try things like this. And mybe we´ll find, that there will be a better way – re-thinking things is hard, and it´s even harder if you have to solve a specific problem within a certain time frame. And at the moment there are just not enough “Waldos” and “Vjekos” available, which we could hire as consultants.
I makes sense to spend time to think about this “cloud” and try to convert als cons into pros. But does the Navision oooops Business Central Team do enough to support us with that challenge? They just depricate the older concepts as fast as possible to push us, while the new versions are not really “ready for use”
Well … changing the name of the product is definetely something, they are very creative at.