Stage Mirror Approach – A technical framework to solve the problem of Technical Obsolescence

Technical obsolescence is when a system or service is no longer wanted or needed despite still being in working order. In the IT and business world, this mostly happens when software is updated to a new version, reducing the relevance and functionality of the previous one. A relatable example is how a smartphone functions less efficiently till it’s upgraded to the latest OS. This brings us to the next question…

Why is Technical Obsolescence an important subject?

Innovation and systems improvements are never-ending endeavours. These necessitate continuous upgrading of services and systems to cater to the demands of the evolving market in order to retain value. Failure to do this puts a business at risk of (but not limited to):

Product-market dissonance; where you have a viable product, but its software doesn’t align with how the market relates to the value it brings.
Capital expenditure, either to manage the ageing software or to develop and implement a complete overhaul. Imagine driving an old Nissan Bluebird whose spare parts are scarce, and how challenging its maintenance will be.

Therefore, to guard against technical obsolescence, building a system application that can seamlessly evolve with times and market demands is non-negotiable. But, that’s not all there is to a potentially significant bottleneck. Let’s explore.

Now, while updating a software service to meet recent market standards, technical obsolescence can ironically still be a problem. In such cases, parts of the software become obsolete as they’re being phased into an improved version. Where in fact, what’s best is a smooth transition where upgrades are implemented seamlessly without degrading functionality at any point. This challenge demands a framework that neutralizes technical obsolescence during service upgrades. And this is where Stage Mirroring comes in.

Stage Mirror

As earlier explained, failure to make your software align with how the market relates to the value you bring results in product-market dissonance. Where on one hand, you have a clear understanding of the product you’re building. But on the other, it isn’t serving the market as it should because that understanding isn’t represented in its functionality. With stage mirroring, you are able to have a code that reflects that understanding at each stage. That way, when it’s time to refactor the code base, you will not have a distorted image—through the mirror of the application’s function at component-level

We can align the technical function with the business result by exploring the relationship between technical input and business output

How Stage Mirror creates a seamless relationship between improving business performances/and financial bottom line. Every business system that uses a technical function to provide a service or any kind of value add to the end user is doing so to serve a customer and thereby generate an economic value – so the technical function an application is designed to carry out can be measured in financial terms. This makes it an obvious priority in terms of business process optimisation.

Stage mirror never stops your business. By implementing a staged mirror system upgrade – the application does not have to stop the operation in the sense that it requires a complete revaluation of the system’s function. Stage mirror introduces a rapid response process.

It allows you to release some of the applications and OLD/NEW co-existing (exploiting storage technologies such as Redux).

Business performance: your client will access the latest technologies and see immediate results. This could also foster a better relationship between your clients or users by allowing them to engage concurrently with new and existing features or updates; customer feedback and response can be measured. SM allows your application to integrate easily with other business platforms such as (CRM). Reduce people’s workload, helping them to organise. Financial bottom line (Reducing old tech debt, you start to get debt free, and it allows you to have more room to get ‘Good’ tech debt)

Good Component Lifecycle Practice

Updating complimentary digital assets – this could be software, a rest API or any other key component of the system application. The stage mirror approach allows you to almost automate the upgrade of each component before it becomes a system defect.

It is important to know that each of the lifecycles of the component is a variable – and the system application depends on it and its functions – the lifecycle may be short or long. By maintaining a good component lifecycle, you are enhancing the interchangeability of newer components within the value strings of the system application.

Mapping the lifecycle of the components (lifecycle aware capability) infused in the system application will help you better understand each component’s business benefit. For example, a longer life cycle component may be responsible for business outcomes related to voluminous value add. This information helps to make well informed product and business strategy decisions.

3 Strategies:

Different cases of application current status

Note these examples are related to frontend applications (with appropriate considerations for backend too)

Example 1

Example Staged Mirror with phase:

bank.com/page1 – NEW

bank.com/page2 – OLD

bank.com/page3 – OLD

bank.com/page4 – OLD

This reference is a situation where the application has reached its maximum potential (in terms of business output or inability to deliver the value-add to the customer) and needs usual maintenance bug fixing. This method is very good for situations where the application’s look and feel must be the same between old and new

Pros:

Perfect if you want to release an upgrade faster(rapid response)
Perfect for backend API application switch from EJB to Restful

Cons:

Look and feel (UX/UI) has to be retained and unchanged

Example 2

Complete rewrite

Old applications continue to live when new ready will substitute it

Pros:

Perfect if you want completely change the application style and look and feel
Perfect if technology gap is high (from JSP old primefaces application to latest)

Cons:

Slower it requires an entire application rewrite before release

Example 3

It’s an example that suits an angular js application – If you want a rapid response upgrade where the component keeping OLD/NEW live, it is reusing OLD/NEW components changing between OLD/NEW

Angularjs provide Downgrade/Upgrade component.

Pros:

Reusing components OLD/NEW
Perfect if the application has not reached maximum potential and requires new features to function.

Cons:

Look and feel must be the same
Only Angular (not suitable if you want to change framework)

Lastest frameworks -> Increase compatibility and market share

API Expansion -> More integration leads to more sales

Latest technologies software -> More likely to have an employee that enjoys the work (cheaper than finding ultra skilled people for oldest technologies, e.g. COBOL)

Lastly, Tech < > Business Output

First of all, as usual, we need to consider start point, is it a monolith, a micro-service just an API also we need to consider what is the purpose of the service under investigation (file manipulation, transactional operations, Web Service REST or SOAP)

After this…

In the case of a monolith, we need to consider and study if it makes sense to transition into a micro-service architecture – adopting the aligned technologies, both at the framework and programming language level.

E.G.:

Transactional operations -> Java

File Manipulations -> Python

REST API -> NodeJS

Micro-service API case

If we need to upgrade a micro-service API in case we adopted the spring framework, we can keep the business running simply by adopting Spring guidelines to upgrade

We can upgrade API endpoint by endpoint, deploying the system on a different port and keeping the old system running in this way; we upgrade one by one (or set by set) transparently

Monolith case

Analyze if it makes sense to adopt a micro-service architecture; in the case of older monolith design, we can think it is possible to decouple the application splitting Front-end/Back-end all this depends on the business case and study.

A good prior business discussion analysis helps to decide which upgrade strategy to adopt for.