Retailers have spent much of the past two years moving faster than they expected.

The pandemic pushed more commerce online, changed customer behaviour, and forced companies to introduce digital capabilities that, under normal circumstances, might have taken years to plan and deploy. But getting through the initial disruption has exposed a different technology problem.

Companies can modernise an application. What is much harder is becoming consistently good at modernisation.

That distinction matters as retail technology becomes more distributed.

On October 15, 2021, McKinsey wrote about the growing gap between the speed of change outside retail organisations and their ability to respond internally. Among the capabilities it identified as increasingly important was an adaptive technology backbone that could evolve as customer expectations and business models changed.

The architecture discussion had already been moving in that direction.

In April, Gartner advised digital-commerce leaders to think about architecture in relation to business outcomes before choosing a commerce platform. And on October 25, InfoWorld contributor and software architect Lee Atchison examined a trade-off that many engineering teams have encountered firsthand: microservices can make individual pieces of software easier to own and change, while making the overall environment more distributed and, in some respects, more complicated.

Meanwhile, the MACH movement—built around microservices, API-first design, cloud-native software and headless architecture—was gathering momentum. By May 2021, the MACH Alliance said it had grown to more than 30 member companies across three continents.

None of this suggests that modular architecture is the wrong direction.

It does suggest that breaking a platform apart is only part of the job.

That is where work published a year earlier by enterprise technology architect Ashwaray Chaba becomes particularly interesting.

In the March–April 2020 issue of the International Journal of Research and Applied Innovations, Chaba introduced what he called the Reusable Enterprise Commerce Deployment Framework, or RECDF.

The framework does not try to invent another cloud platform, another integration technology or another variation of microservices.

Its more useful idea is simpler: when an organisation spends months figuring out how to modernise one major commerce system, why should it solve essentially the same transformation problem again when the next system comes along?

The problem behind the technology

Anyone who has worked around a large commerce environment knows that modernisation rarely ends with one application.

A retailer may start with its customer-facing platform. That effort forces teams to make dozens of decisions: which capabilities should be separated, how services should communicate, where data should live, how releases should work, what should be monitored and which team owns what.

Then comes order management.

After that it may be inventory, payments, product information, customer data or fulfilment.

The applications are different, but many of the questions are familiar.

Integration has to be designed again. Ownership has to be negotiated again. Deployment standards have to be agreed upon again. Teams rediscover lessons that another program may already have learned.

Chaba’s framework focuses on that repetition.

RECDF brings together strategic planning, architecture modernisation, integration and data, operational practices and organisational capability within a common enterprise-commerce model.

It is worth being precise here.

Microservices were not new when Chaba published the framework. Neither were cloud computing, APIs, DevOps or incremental modernisation.

His contribution lies less in the individual technologies than in the way he organises them around a different objective.

Instead of asking only, “How do we modernise this application?” RECDF asks, in effect, “What should we retain from this modernisation so the next one does not start from zero?”

That is an important change in perspective.

Software engineering has always been built around reuse. Companies reuse code, services, libraries, infrastructure templates and architectural patterns.

Chaba extends the same thinking to the transformation process surrounding the software.

A successful migration produces more than a new system. It produces architecture decisions, integration patterns, deployment practices, governance rules, operating knowledge and lessons about how teams should work together.

If all of that disappears when a project closes, the organisation has modernised a system without necessarily improving its ability to modernise the next one.

Or, put more simply:

Modernising one application completes a project. Learning how to repeat the process creates a capability.

Why this matters more in modular commerce

The move toward more modular commerce makes this question especially relevant.

A traditional platform might contain a large number of business functions within one closely connected system.

In a more composable environment, product information may come from one platform, search from another, payments from another and order management from somewhere else entirely. Customer experience, inventory and fulfilment may each evolve on their own schedules.

That gives businesses flexibility.

It also means there are more relationships to manage.

A shopper does not care that six different services were involved in completing an order. The shopper simply expects the price to be right, the inventory to exist, the payment to work, and the package to arrive.

The underlying systems may be independent.

The business outcome is not.

This is one reason the shift toward microservices cannot be viewed only as a decomposition exercise. Atchison made a related point in his October InfoWorld analysis: service ownership and organisational structure matter, and moving to microservices can create additional complexity even as it solves other problems.

RECDF treats those organisational and operational concerns as part of modernisation itself.

That may be one of the more practical aspects of Chaba’s approach.

Many enterprise technology problems occur in the spaces between systems and teams. An API works, but nobody clearly owns it. Two groups adopt different release practices. Monitoring is inconsistent. One modernisation program establishes an effective integration approach, while the next program develops another.

The individual technologies may all work perfectly well.

The transformation still becomes harder than it needs to be.

Chaba’s framework argues that those lessons should accumulate.

Not a new technology, but a different way of organising the problem

RECDF is best understood as a synthesis rather than the invention of an entirely new technology.

That description is important because it puts the contribution in the right place.

Large enterprises are rarely short of technologies. They have cloud platforms, API gateways, integration tools, deployment systems, monitoring products and architectural patterns.

What they often lack is consistency in how those pieces are applied across multiple transformation programs.

Chaba’s work attempts to organise established technical and organisational practices around that larger problem.

In doing so, it changes what “reuse” means.

The reusable asset is no longer only a software component or architecture pattern. It can also include the decisions, practices and organisational knowledge required to move a complex enterprise system from one state to another.

Published in early 2020, RECDF preceded several of the industry discussions that became more prominent over the following year. The framework’s emphasis on repeatable modernisation fits particularly well with what the retail technology industry has been discussing throughout 2021.

Gartner has been pushing commerce leaders to connect architecture decisions with business outcomes. McKinsey has emphasised the need for retailers to become more adaptive. InfoWorld has highlighted the operational realities that accompany distributed systems. The growth of the MACH ecosystem reflects the industry’s appetite for technology that can be assembled and changed more independently.

The natural next question is how companies manage all of that change repeatedly.

RECDF offers one way of thinking about the answer.

The real evidence will come from what happens next

There is an important caveat.

A framework that makes conceptual sense is not automatically a universally proven operating model.

RECDF combines established practices into a broader approach, but its complete value would ultimately need to be demonstrated through independent use across different organisations.

And the most interesting test would not be whether a company completes its first modernisation successfully.

It would be the second.

And the third.

If an organisation modernises another major capability two years later, does it spend less time rediscovering architecture decisions?

Are integrations designed more consistently?

Do teams inherit deployment and monitoring practices instead of rebuilding them?

Does experience from earlier programs reduce duplicated work or operational risk?

Those are much stronger measures of reuse than simply showing that one migration succeeded.

They are also the questions that will determine whether the idea behind RECDF has lasting value.

What happens after the first modernisation?

For years, enterprise architecture conversations have centred on what should replace older monolithic platforms.

Cloud.

Microservices.

APIs.

Headless commerce.

Those decisions remain important. But by late 2021, another question was beginning to emerge underneath them.

What happens when the company has to do it all again?

As commerce systems become more distributed and businesses are expected to change continuously, organisations will have to decide whether every major transformation starts with another round of architectural discovery, integration design and operating-model decisions—or whether some of that work can become institutional knowledge.

That is the problem Chaba’s framework is trying to solve.

RECDF still has to prove itself through broader independent implementation. But the problem behind the framework is already visible.

Enterprises do not simply need architectures that can change.

They need organisations that learn how to change them.

And in the next phase of digital commerce, that may prove to be the more meaningful shift: not merely moving from monoliths to microservices, but moving from one-time modernisation to repeatable change.