How to deal with change management: plan and actions

Pivoting: when company changes its offer

In my experience, working for a service company, it happens 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 company is dealing with small or big changes every month.

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 the requirement of implement a 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, but still everyone stop to the 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 deal with corner case, maybe a better MCP code can be written, but most of the time it never consider refactoring and whole project review, it never remove 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 the company cares about their customers (and the money that comes from them), they must care about their data.

The best practice on implementing micro service architecture is that a each service has its own database. But this might be or might not be effective, depending on current status of the system.

Sometime SOA is introduced as redesign of existing system, and database structure does not permit to define a specific db for the specific service.

Also a well designed micro service is scalable and deal with a small set of operations, so it what local db is sensible choice for a group of mini and micro service, together implementing a service.

To give an example, lets consider a data import service. In a micro service architecture it 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 be scalable 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, made more scalable, less scalable, depending on the demand.

Where I want to highlight here are the Databases (and message broker) change 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 lifetime as long as you can.

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 you can plan 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 (migrate dbms or migrate structure, same advice) 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