How to deal with change management: plan and actions

Pivoting: when company changes its offer

As of my experience, it’s usual that some service has no more effective, so customer stop to pay for it.

There are big software pivot that everyone can see from the marketing news, for general public, but internally every IT companies deal with small or big changes every month, and every week.

Changing is not an optional task: change must be implemented and managed.

Planning the change vs telling the aims

I my opinion there should be a cycle behind change management, as it is in every software development field:

1. communicate requirements behind the change: what to change
2. plan a strategy for the change

The most conflicting staff involves time-to-market and technical debits

Underestimate the technical debit impact

This is a big issue on AI and LLM era, where everything looks easy to implement, as long one keeps stopping to demo-stage of the project.

When you adopt MCP (on IDE or on repository like GitHub) to deploy the power of an LLM, but just stop at the prototype stage you miss out two important quality:

• corner cases bugs
• changeability level of the code (also readability of the code)

I am astonished by the way an LLM (not) deals with corner case, maybe better MCP & LLM code can be written, but most of the time it never does refactoring or whole project review, it never removes staff from the code, and when asked to review the whole code the outcome is something random, far away from any kind of coherent specification.

Breaking the architecture: is “Domain” in DDD optional?

When arranging the backend code in micro service the key is to define a cohesive set of domain, one for each micro service.

It is important to be elastic on this:

• the set of domains can change
• some change can break the domain limit for a while (but it is a technical debit that must be fixed)
• change of domain set must be managed as architectural hop: plan to move every thing on new set, and switch off old services

Deal with database structural change: the biggest challenge

If company cares about their customers (and their money), it must care about their data.

The best practice on implementing micro service architecture is: a service <-> a database. This might be or might not be effective, depending on current status of the system.

Sometime SOA is introduced as porting strategy for existing system, and database structure does not allow to define a specific db for the specific service.

Also a well designed micro service scales and deals with a small set of operations, here is where local db is sensible choice for a group of mini and micro service, together implementing a service.

As example, lets consider a data import service. In a micro service architecture this can be compound of some more mini and micro services:

• ImportControllerEngine: an Import Engine, that automate the data import process
• DataRetrievementService: a service that retrieve data from external source
• ImportPolicyConfigService: a service that expose an API to insert an import process policy, including pickup time and data mapping from external to internal structure
• DataImportService: a service that actually read import data into the db

With this architecture, DataImportService and DataRetrievementService must scales to deal with multiple data retrieve and import. ImportPolicyConfigService has less demand of scalability, it can also provide a facade to expose API to generate event for ImportControllerEngine.

This architecture can be changed, enhanced, splitted into multiple scalable pieces, or grouped, depending on the demand.

Here I want to highlight the Databases (and message broker) changes that might be required in response of business demand.

There is an ImportServiceDB and a targetDB, both structure may requires change during the lifetime of the service, and if you want to keep making money, you should keep the span lifetime of the service as longer as possible.

ImportServiceDB changes

The data structures are subject to change whenever a new import policy or new import feature, like source filtering, source retrieve feature, source-to-target changes, etc.

These changes are not something one can plans upfront the design of the architecture. What can be done is to design the plan of the change, then implement it.

The general advice for database migration (dbms provider or table structure) is:

• add the code to write new data to newer structure or db
• run the code to migrate (or use a migration tool)
• replace the code that read data, to read it from new structure
• remove the code that write to older structure

Without a clear definition of domains of each micro service, the only option would be to inspect the code for each service, and find what are the change to be made.

Also without a good coding practice (read: clean code, class design), the change can be difficult, or almost impossible without an upfront code review and refactoring stage.

targetDB changes

The targetDB can be external from the ImportService, so changes can involve other services as well their micro and mini service composing them. Again the change is not something you can plan upfront: you just need to design and implement it. Following the general advice of migration process, coordinating step by step for each service involved on the change, and keeping the whole system working.

Conclusions

The most important element to deal with when migrating database structure is technical debit, being on domain definition, in the architecture, in the code, when a change is asked the required time depends strongly on the state of the system, and clean code is not optional.

So to evaluate a work it is important an insight glimpse at the status of the system at all level, starting from API, below to architecture arrangement, and then in code implementation.

In my experience, technical debit is the most underestimated tracker on issue tracker system: most of the time is misused, ignored, confused.

So the real effective way to evaluate a change is to inspect the code. That is time consuming by itself.

My Consulting Services