Blog

Business
Application Modernization – Second step: Working smarter not harder
8 October 2020
by Jean-Paul Lizotte

In Part 1 of our article about Application Modernization, we talk about reinventing ourselves. Why? Because application modernization is much more than just taking an existing application and modernizing its infrastructure, platform, internal architecture, etc.

Often, the most difficult part comes from a reluctance to accept the need to change. To understand the need to revisit traditional structures. Remember that such a process should be divided into several stages. This is what we will be talking about in Part 2 of this article, diving into principles and processes. Adding a touch of DevOps to it. Yes, again!

It is truthful to say that the choice of technology could be crucial when you decide to make the leap into application modernization. But it is as important to remain objective, to respect the steps, and above all, to communicate well. This is our next subjet: working smarter, not harder.

Eyes wide open

So let’s talk Principles and Processes. Among the “healthiest” and most effective, in my opinion, are those that are cyclical and have a balance between the desire to push forward and the thinking done behind the scenes.

For those who have read our white paper about SecDevOps: People, Process and Product or followed my webinars, I frequently refer to the Deming wheel. Which is also known as the “PDCA” industrial process. What I find particularly useful in applying such a process are the steps in which the forces are evaluated. Both at entry level and also the results at exit level. Typically, the organizations I help are doing quite well early in the cycle. It’s at the end, when you have to assess yourself and evolve, that things get a bit tricky.

When Objectivity becomes the main objective

In a delivery plan for an application modernization project, it is useful to establish a project charter as well as to identify the milestones. And to measure the passage or path to reach these different milestones. Again, I believe it is useful to quantify and qualify these “passages”. That is so we can establish whether an adjustment to our process is necessary. Or if the adjustment we just implemented has given us the desired results.

The DevOps effect

If there is one thing that really annoys me (because to me, it does not make sense), it is when someone who has his hands on the reins of a project and who has vaguely heard about DevOps says, “We’re going to put a DevOps on this”. As if the burden of a DevOps initiative could rest on the efforts of one single individual. A sort of new-age guru who would become the cornerstone of our success and possibly our failures. Even though I am the lead of such a practice at Emyode, I am nothing without the people who make up the teams and who make it work. And the whole credit goes to them.

Without relying too much on the term itself per se, DevOps is after all a combination of two “concerns” that used to be separate, DEV and OPS. And we could easily represent them by these two ideals: to evolve (DEV) and healthy living (OPS). The fact that our two friends (DEV and OPS) seem to have separate agendas can indeed negatively affect our ability to deliver our projects. So I say: Let’s credit the industrial age here for allowing us to see that in order to deliver with agility and ease, it can be smart to see yourself as part of a large production line.

Chaining and solidifying all the links

How can we do this? First, it is important to recognize that from conception to delivery of a product or project, there is a range of stages, each just as important as the next. Additionally, moving up the chain (or advancing) should teach us to visualize the importance of each of these stages. Or better yet, understand the people who serve in them. And then we have to learn how to better make the transition between receiving the work of our colleagues “upstream” and the passage of our own efforts, downstream. This is all DevOps stuff.

 

So it becomes clear that “compartmentalizing” work will not serve us as much as we might hope. Simply because this way will cause extraordinary communication efforts and therefore additional potential problems. We don’t need it. Let’s break the “silos”.

 

The technical debt

Objectively speaking, still, if we decide that it is necessary to modernize part of our IT services, this means we have already fallen behind. Admitting it generally is the first step before you can rectify the situation. Once you eliminate any potential source of bad faith. When we know that everyone is working as much as possible, then it should become obvious that the problem lies in the method. We should know very well that if some of our competitors manage to stay up to date, then why would we be any different? Right?

I therefore suggest that you consider this: It is useful to measure how far behind we are or at risk of becoming obsolete. This, in order to properly assess where we want to be and when we want to be there. Ever tried using a map to get somewhere without first finding out where you are starting from? There you go.

 

Choosing the right technology

Perhaps this will come as a surprise, but most technological choices are often a little “awkwardly chosen” to meet OUR needs. How do I come to this conclusion? Simply because IT specialists, for all their plethora of tools, still manage to put themselves in compromising situations. In particular that of generating technical debt, precisely. And while we offer our customers to improve their work (their “business”) with tools, we find it difficult to do the same with ours. This is called the poorly shod shoemaker syndrome, which also suggests that a major shoe merchant may be, in fact, incompetent.

This is one of the most common mistakes with application modernization. And that stems from the fact that we are much better experts when providing services than when consuming them. Because a customer is useful!

Here again, it stems from the approval cycle to which we are entitled to when we provide services. Something that we rarely do for ourselves. The famous “C” in the previously stated PDCA: we miss it regularly when we are looking for ourselves. And so our technological choices become a little impulsive, imposing constraints and artificial limits that prevent us from delivering our projects properly.

Our expertise is a barrier to objectivity sometimes. But it is less so when serving a client because of the “challenge-response” we get from them!

Don’t be afraid to ask for help

I want to keep this chapter short. It might seem a little hypocritical not to say that we are here to help you. Our mission, our raison d’être, is to become a catalytic agent for your projects. But in principle, we are all afraid of exposing ourselves and possibly making another mistake which could increase the complexity of our situation.

In DevOps, one of our principles for limiting risks is to apply changes incrementally. Using “baby steps”, we often say. So when we go looking for help, through external or internal collaborators, we gradually invest where success is most felt. Or better, where it is measured. And that’s how we operate. So, by all means measure us.

Communication, the main ingredient to collaboration

Let’s keep in mind that one of the obstacles to a successful project is the existence of isolation of the critical parts in the delivery chain. We are living in an unprecedented era. We are becoming acutely aware of our gaps in communication and the negative effects of the lack of proximity to our allies.

How many business models will outrightly fail if they fail to scale at the speed that the business is forced to go? Have you considered how many of them could be salvaged if these businesses were naturally able to communicate and reorganize? Are we required to continue doing what we have always done, because it is not being discussed?

If there is one persistant part in my speech, it is this one: Evolving requires a well-measured and considered collective movement. This is what makes us gain ground.

Let me make another suggestion: It is always useful (again) to consider its “cyclicity” in its operations. What I mean is: knowing that there will be an end, a near end of a delivery cycle, this allows us to gain a certain independence on the current structure of a process or way of doing things. If reinventing ourselves is part of our daily lives, how much harm can we do by trying to do it again? Not a lot.

Is this an incredible opportunity? Absolutely.

Simple? Yes. Easy? No. But the things that are worth it seldom are.

Conclusion

If you are considering making a change in your critical business applications, consider driving their evolution in “bitesize”, cyclical parts. Don’t make it a Herculean marathon. You will see several beneficial effects to going this way, which are further enriched with time. Consequently, you will be in a better position to consider what changes will be the instrument of your success. And the origin of the delivery of projects on time and on budget.

Minimize your risks by giving yourself a chance to assess yourself and evolve. Recognize when you are “shoveling ahead” or only lagging behind in uncompromising processes.

You deserve better. After all, you should be able to say that you serve yourself as well as your customers. But if you have the wisdom to recognize that support will be needed to regain some ground (such as with Application Modernization or with DevOps), think of us.

JP

Related articles

Read news
Application Modernization – First step: Reinventing