Application Modernisation : inevitable complexity or just in time common sense?

Are you working on next-gen of your systems or does your enterprise has euphoria around platform re-architecture or modernisation?

Well.. then lets take a look at a no cost option of achieving a good architectural foundation! Scope here is to really do what is basic and requires low/no cost to re-define cultural influences & enable operating environment conducive to architectural thoughts and opinions.

Lets define Modernisation and the context in which I am presenting my thoughts..

Context of Modernisation : Outcome based understanding of modernisation today is being more Elastic, Ready to Scale, Cross Platform and inevitably moving to cloud…. however, this definition is more used as a goal setting by the management layer of enterprises than it is to bring foundational changes in your teams outlook around technology. My view of modernisation is the later — the very process of revisiting basics before you attempt this glamorous outcome!

Long Running Apps in Prod : How well & How long can we repair a running vehicle?

Major revenue or expenditure stems from the fact that many organisations are thriving on the need of pumping life into a vast populous of apps that are screaming for architectural help but no one wants to radicalise technology at the expense of slowing down business OR directly wants to do Elasticity , Scalability , Cloud or SRE etc.. So yes, there is a big use case for spending time on the basics ( stopping the vehicle) before taking on such optically bigger things which are essentially could be more of configuration than code..

Let’s begin to deep dive into this context of Modernisation!

Modernisation is generally thought of as a esoteric skill only possessed by Architects, but it can often times just be a simplistic & pragmatic approach of looking at things as they are and why they are — just about everybody with applied common sense can attempt it.

Let’s explore if Modernisation is really always needed to be marinated in complexity?

Approaching modernisation as “outcome” may not be the most yielding effort especially if you are dealing with work force who has been around in the battle field for too long as their ability to question everything will diminish with time.

New to the team and want to pluck the stars?

Especially if you are getting into a new team with this goal, it makes imminent sense to not rock the boat but get in the core zone of how team feels by simulating the evolution and doing some very basic observational exercises and not just prescribing things — which is what I call “Thinking Mode”

In my view, we need to just re-orient and get the work force into “thinking mode” before we do anything which even has optical semblance with Modernisation.

Here is a very vanilla staging pattern of how an enterprise or a group can start modernisation without having a need to scream about it..

Natural path for Enterprises to build foundation for Modernisation

Remove the outcome to ensure discussions are mentally welcomed and generate opinions , debates which generally require research which is what we need to have for a clear blueprint of what exists before we can think of what can be done. Once the superset of all such pain points, influences, patterns & observations are ready — we have a perfect ground to begin the game!

Teams would involve their good ego into en-cashing the exposure this exercise would generate , back their opinions/views which will recursively fine tune everything if you have a good anchor moderating the entire paradigm shift.

Once such list is ready, final step is then to re-imagine & just re-do the stuff which —

1. Pains the most,
2. Has most wastage in terms of time or network costs,
3. Brings more learning to the team and
4. Stands scrutiny to the tests of infrastructure.

Before I end, let me convincingly admit —

Simple Observations are enough to have a good backlog of technical to do list for Modernisation.

Lets look at few of such..

Is your Transactional data sharing same perimeters with Non-Transactional Data

Do you know what Data you report more vs Data you manage the state of?

Clear understanding of Customer Journeys -> Application Offerings -> User Behaviours

Is your Culture democratic around Design

Process is equally important to expedite your Architectural Outcomes — Never treat them secondary

Figuring out right balance between public data, reference data & private data perimeters

Documentation is also a part of modernisation , it is going to save tremendous post production costs & radiate clarity to new team members

How well you can calendarize your Application Usage to understand and more importantly foresee demands

Instrumentation & Network Analysis : Understand a sample of full network trace of your Application — this will open your eyes forever

How clearly your logs can scream & where can they be heard or simulated

Generate a graph of dependencies to understand your technical stakeholders & configuration nuances that come along

Finding Greatest Common Denominators , correlation of behaviour with data contracts

Can each layer of your design stand on its feet if other layers were to be mocked/abstracted ?

Keep looking till you identify Components correctly ( especially if your systems have evolved)

Know what you don’t know

Hope you could resonate with these thoughts! If you do then, Follow for more perspectives..