Technology procrastination, strategy and methodology (transition from NAV to Business Central)

One of the things I love about participating and being a “technical community” is having the opportunity to enrich yourself by sharing experiences and points of view with a multitude of people, from different industries, company sizes, partners and customers.

However, it strikes me and I contemplate with a certain skepticism and amazement (and even pity) how there are companies that completely lack a technological strategy. And the worst thing is that in many cases this is the case “Technology consultants” (WTF!!??).

It is certainly difficult to always be "on the crest of the technological wave", talking about a dynamic market means losing reality (and if you move in the "Microsoft universe" even more so), in fact, as I write these new ones will soon be released " functionality” from Dynamics 365, Office 365, Azure, etc.

Sometimes I think this is precisely what overwhelms some companies, who see how they are always late for the train and end up seeking refuge in their stable comfort zone, while they see from the window that the eye of the storm is getting closer every minute. I like to call it “tech procrastination”.

If you've read this far, nodding consciously or unconsciously, congratulations!! I think that's a good sign. If not, I invite you to skip straight to the final note.

I will skip the generalities and focus my example in the world of Dynamics 365 Business Central (I know, you were waiting for it 😊)

Advantages that turned into nightmares

Since ancient times, Navision/Attain/NAV (NAV from now on) has overwhelmingly been a development platform, incorporating features that help run the business.

It's true that with relatively little effort you could get almost immediate results, but obviously... as Spiderman's uncle said: “With great power comes great responsibility.”and as the years went by, there were more modified objects in our DB than unmodified objects.

Of course, one of the great advantages of the product has become the worst burden in current times, where it is difficult to conceive how an upgrade (or migration) of a version becomes a similar investment to the initial one (or sufficiently high).

But from my perspective, the biggest advantage is what has become the worst nightmare imaginable: speed and simplicity.

The explanation is very simple, in our nature it is to invest the least possible energy to achieve a goal, and in the end this is a "fertile ground for bad practices". If we add to this that the vast majority of executing companies are small, where the volume of projects is medium or high and resources are limited... we arrive at the following identity lawWhere "NAV Consultant = Juan Palomo” (equivalent to “I will stew it and eat it”).

A quick example: imagine you are a consultant (or something very common in this industry, you were a developer and when the time came you became a consultant). You are carrying out the realization of a simple project. Collect the requirements (a classic), without too many details and the customer validates them. It's time to get started: do you create a technical design document? – No, because I am very clear about what needs to be done and I won't write it for myself.

do you do unit tests? (assuming you know what it is) – Well no, we have little time, we have to invoice now. Better yet, we put it into production, test it at the customer's home... and gradually adjust it "hot".

Have you kept track of it? – Obviously inside the object code I put my initials and the date (good, good... let's go).

Objective achieved: it is filled out, ergo you can invoice... if something arises we will adapt (in total it is up to me to do it, it is my project).

Well, now I ask you, What do you think happens when a person has been working this way for 5, 10, 15 or 20 years?

Self it's a habit, and we are animals of habit. This is part of the comfort zone I referred to at the beginning of the text. But don't worry, there's always time for change.

You already know it, that is, Microsoft announced the model change as early as NAV 2016, when the v1 extensions were released. Well, much earlier, when good practices with "clean code" and less invasive development models began to be promoted.

But obviously there is no time, you have to keep invoicing, you have to take care of customers, make changes (probably in production)… in short “technological procrastination”.

At the same time, the world moves forward, changes occur, the product has already transformed... and what you were doing simply doesn't work anymore.

The wonderful world of ISVs and/or reference consultancy companies

Does what you read seem alarming to you? If so, it's because you've experienced it, in your own skin or in that of your neighbor. Don't worry, there was nothing similar to what happens with ISVs and partners of a certain size.

There is always a shortage of professionals in the technology sector, especially when it comes to specialists in Business Solutions, even more so.

Returning to the previous example of our Juan Palomo (currently "Senior Consultant & Project Manager"), with some experience you want a change of scenery and decide to take the leap towards a larger project (law of supply and demand).

What do you think happens when you put people with this profile to lead teams and manage your products?

Basically what's expected, we do what we know how to do, and our kids start to pick up a lot of these bad habits.

In my years of experience, one of the things I had to do was verify existing implementations, logically all with customizations. But the bloodiest thing is always when you see “customizations on a vertical solution” (and again… WTF!!??)

And what is this? Very simple: the ISV has developed a solution based on NAV, more or less integrated into the standard. Ideally what you have is one product (probably in different versions), but standardized, so that it is parameterized for each customer's implementation.

But the sad reality is another, it happens that when the implementation is carried out, sometimes due to lack of knowledge of the solution itself (yes, it happens, believe it or not), sometimes because the customer's expectations have not been mapped with our project plan... customizations are made to cover some functions, which are essential for this customer. Well, we already know that we have to invoice, that in the end what matters is that the customer is satisfied and all this.

What is the end result of this? As you already guessed, if you have “n” implementations of your vertical solution, you have “n” different versions to maintain. Unsustainable.

Technology methodology and strategy

So far we have talked very little about technological strategy, rather it is a problem of methodology. But Don't you think they should go hand in hand?

In my humble opinion, technology strategy should not just be limited to what technology we use or where we will focus on our innovation or research projects. Technological changes are accompanied by changes in working paradigms, development, implementation, support provision… and, of course, sales and pre-sales.

So let's talk about The technological strategy is and must be transversal to the company's strategic planregardless of sector or size.

So: dear friend, if it is within your power, think twice before appointing Juan Palomo as CTO (or similar position) in your company. It may be true that our friend is already sporting gray hair, after years of battles and struggles for the company, if he deserves it, but first you must check that all of the above is clear to him. That is, we need to know how to raise our eyes and look forward, distancing ourselves from everyday life.

Of course, much more important is that, as CEO, you are clear that technology strategy is key.

My advice

I'll end as I began by talking about the important role played by the technical community. We must lose the fear of sharing experiences with other companies, no matter how competitive they may be.

Summing up:

  • Maintain as global and independent a vision as possible. The world of monolithic solutions is over.
  • Attend community events (user group meetings, Saturdays, partner days, directions, Business Applications Summit,...
  • Don't hide behind the lack of time or amount of effort needed to change course. DON'T PROCRASTINATE.
  • Remember that it is never too late to change or rectify the course, but it must be planned and translated into a strategy, also supported by company management.

Final note

Make sure that This vision is shared between business management and technology management. Otherwise change company.

If you are the CEO and don't agree with this, I'm sorry to tell you that your company will survive as long as inertia and past income allow.

If you want to read other articles similar to Technology procrastination, strategy and methodology (transition from NAV to Business Central) you can visit the category Power Apps.

Leave a Reply

Your email address will not be published. Required fields are marked *

Your score: Useful

Go up