So where are we with our application modernization?
In part 1, we stressed one thing: there must be a real desire to reinvent oneself. So it’s not just about taking an existing application and modernizing its infrastructure, platform or internal architecture. We have to make this “reinventing ourselves” part of our daily life. Because the hardest part often comes from reluctance to accept the need for change. And when you understand that, the need to review all traditional structures, suddenly becomes clear.
We also talked about it as a process that you need to divide into several stages that are more palatable and cyclical. Part 2 clearly showed that choosing the right technology is important, but so is to remain objective, to respect the steps, and above all, to communicate well. It is all about rigor and collaboration.
So what else do we have to think about? Continuity… the logical next step of a good application modernization. Because you have to know what to do now, for tomorrow, this undefined (but assured) future is, where the destination lies.
It’s never over.
If you’re like me, you may be haunted by the desire to leave something behind for the next generation. That certain something that represents the effort of your life. For some people, having raised a family or to have lived in comfort is enough. And I admire them. But I am not satisfied so easily. However, I try to be realistic.
It might not always be easy to let go of a lifetime’s work and have a fair appreciation for it. In fact, it’s a bit difficult to imagine what the future holds for our successors. But I want to stay practical and give you a fairly simple proposition (which I also invite you to try).
It seems obvious to me that all worthy efforts are those efforts we want to invest in. It can be said that time and patience seem to be recurring values, thus allowing us to ensure that the product of our efforts is MORE than just the sum of its parts. This might seem a little contradictory to you, but what I am suggesting here is to save your time and your… considerable mental efforts. Let’s see how to apply that, to application modernization.
Application modernization does not mean improvisation.
From the onset, these words seem self evident. True. But where I am going with this is: that you have to be able to weigh the pros and cons between a conservative, critical and more innovative mindset. Yes, there is a saying that lends itself well to expressing this thought: if it ain’t broke, why fix it? Well, that’s where all the subtlety lies.
Don’t wait to be “broken” – or in this case, “outdated”. It is just as deadly. To evolve is a balancing act worthy of a tightrope walker! The term is more appropriate than you might think because, if you notice, the acrobat measures and takes steps that are suitable for him. Application modernization is a little similar… well, sort of. Just keep in mind that a tightrope walker, is equipped to be able to stabilize and recover in the event of wobbling!
And that’s a good allegory… if you will take my advice.
Consider risking only what you can afford. And when you do, make sure to place each action in the right spot in time. That’s the basis of all experimentations.
Validate your assumptions. Always and again. Think of all those testings and validations as a safety net in your application modernization process. Personally, I find the completion cycles to be just as relevant in macro mode as they are in micro mode. And whether you’re looking at delivering a full MVP or delivering a specific feature, I don’t think it’s less relevant to test and adapt for one more than it is for the other. Simply put, this is how you will survive the tightrope walk. Adapt you processes to best see and control risk.
Few can afford a big fall!
To live = To Survive
I am not suggesting that you only live in tense moments here. Using best practices (and particularly those of DevOps), there is nothing that dictates or forces you to takes risks and without a net. Rather, give yourself the space to do your testing in a safe place, but be consistent with the final reality. And if that proves to be too much of an exercise, maybe you should reconsider the scope of what you are going to deliver. No one is telling you to take unnecessary risks. So don’t take any. But it is true that everyone makes mistakes. So rather than trying to establish perfection in your processes, I suggest you incorporate the element of human error.
This is a well-known principle in information technology. Even if we deliver something that is supposed to have considered everything, we invest part of our “development cycle” in a journal or a “logging” system where we will dump the “unexpected errors”. I have a lot of difficulty writing this sentence without smiling. Because it seems to rationalize everything I say in one fell swoop. I sincerely believe that errors come in two flavors: those we expect and those we don’t see coming. And it is this gap that causes deep discomfort between projects that move forward and those that fail. There is only one variety of project that consistently survives: the one that did not do everything to prevent errors, but to mitigate them.
Full speed ahead! Just wait a second.
Think of it this way: We cast a much wider net when we attempt to mitigate than to address a specific problem with precision. Tu continue the metaphor, it’s much easier to put a net below the entire tightrope than to predict where exactly you’re going to trip. And what a relief to know that a fall won’t be fatal. You could almost make a career out of it then. Cheerfully! Oh wait a minute… that’s what I do!
Rarely are those opportunities that allow us to rush forward without regard for what lives below the surface (sounds ominous, eh?). In your application modernization project, you probably know where you are going at this point. But what might be less obvious is, how you’re going to pick up the next cycle and make sure you’ve incorporated an element of evolution for your next big release. Where will the acceleration you need come from and what will be the vehicle of your success?
I find that there is nothing more human, apart from our faults, than our love for our tools. In fact, in my opinion, this is possibly the best way to organize our ways of doing things with our won means. You know, in DevOps, it is often said that the elements of success are “People, Process and Tools” and I believe that this will hold true until the end. Our processes exist to protect us and to allow us to learn; our tools are there to give us strength where we lack it most. Literally, leverage.
And however you might look at it, I can confirm it’s true… and almost universal. Our fault most often lies in our review methods, our “post-mortem” evaluations. But even worse, in my opinion, for fear of exposing ourselves to even more faults, we seem to favor a kind of homeostasis where the entropy of being “stuck to the ground” ensures our survival for the next cycle. We can’t fall. It’s absolutely false. If you and I are here, the fish had to come out of the water. And our first technological revolution, the operationalization of fire, would otherwise have been difficult. And we did it without a plan, too! Risks must be taken. Just control where and when you are going to make errors and you’ll do fine.
Try not to see your destination as an end point. Think that your app delivery will only be a step in a never ending journey. Not only will you see it more clearly, but you may better divide your project into digestible parts and stages that have resilience built in.
There is nothing that pleases me more than seeing people equip themselves with the means to experience a project delivery with a smile. One of the most memorable moments of my life was when I kicked off a release from my phone, sitting on a train. I’d been blessed with a host of exceptional collaborators and clients to get there. But what I like to offer in exchange is a great adventure. One where the destination still lies in an indeterminate future, but a certain one.