👴🏻 🤧 🗂️ We sell Architecture Refactoring to a client or what is the problem of developers 🎈 🗒️ 🎳

Architectural or design refactoring is always a painful problem on a project. The benefits of refactoring are obvious for us technical specialists, but it is often difficult for the client to sell and substantiate this idea. The main reason is that we technical specialists do not know how to talk with business.

The main problem is communication between technicians and people who make money. They speak different languages, although they are trying to solve the same problems.

This article is a translation of the original from English: Architecture Refactoring and Design Refactoring How to Sell it Client . If you have colleagues who do not speak Russian, they can read the original on my bulg.

The benefits of refactoring are obvious to all technical professionals, but often we cannot convey this idea to the business. Why does this happen? We skip a few minor but very important steps for the business.

We divide the whole process into 6 simple but necessary steps:

Determine the cause of the problem.
Decide what changes need to be made.
Justification of the decision
Make a refactoring plan
Create roadmap
Present your decision

Find the cause of the problem

This step is quite familiar to us as technical specialists. Consider it with real examples.

The build crashes after almost every commit.

There are several reasons why this can happen:

Application components are very closely related and dependent on each other
Application components do not have proper isolation
Lack of unit tests
Lack of SDLC processes and CI / CD

One more example. Application deployment takes a long time, and performance problems are also observed.

The main reasons may be:

A monolithic application grows fast and has become too large for one application
The application is large and consumes a lot of RAM and processor power.
The application is complex and not well written

Decide what changes need to be made.

The next step is a bit more complicated, but still familiar and uncomplicated for senior + developers. We are all good technical experts and always know what needs to be improved. And at this moment we make a mistake and run to the client with the words let's do it .

But we are intelligent architects and we will follow our plan of 6 steps step by step.

Based on the previous example with a monolithic application, the solutions are obvious. Break a large, complex application into smaller, independent modules. These are the first steps to a service-oriented or microservice architecture.

Justification of the decision

We will divide this step into two phases: technical and business justification.

The technical rationale seems logical to us. Break the monolith into smaller services, as a result of which we get:

More disparate components
Build problems will not be so frequent
Small services consume less RAM and processor power, as a result - better performance
Separate services can be deployed faster and independently of each other

Justification from a business point of view is a very important step that technical experts often forget about. You must remember what is important for business. That's right - it's money .

In short: if refactoring does not benefit the business - it makes no sense to do it.

Based on our example, you can offer the client the following benefits:

New features will be developed faster
The quality of the application will be better, as a result of lower costs for bug fix and a satisfied user of the application, which also positively affects business
Reduced development and deployment costs
It’s easier to find motivated and experienced professionals who are ready to work with the project.

Refactoring plan

The plan should be clear and detailed. Each iteration should be clearly described and all architectural and design changes should be documented.

Create your plan you must answer the following questions:

What is the purpose of this iteration?
What is the technical and business value of this iteration?
How to shorten the iteration time?

Roadmap

A very important step . Take the time to do this if you really want to sell refactoring to a business.

Every manager and businessman wants to know the answers to two questions:

How much is it?
How long will it take?

Try to break refactoring into small iterations. Each iteration should bring technical and business value. It's pretty hard to sell refactoring for years and cost millions of dollars without any intermediate results.

Each iteration should contain information on the duration and number of specialists needed for this. This information will help the manager answer two basic questions asked a little higher.

Collect project metrics before and after refactoring at each iteration. This will help you to show what technical and business value this iteration brought.

I present my decision

Before you go with your decision to the business, check it with your immediate manager. A side view is always good, especially if it is a business side view. Perhaps your manager has more context and will help you change the plan in accordance with the expectations of the business.

You need to know how to answer the classic question.

Usually when you present architectural refactoring, a business may ask. Why do we need refactoring? Last year we spent enough money on architecture, and now we have problems again.

There is a classic answer to the classic question. This architectural solution was good a year ago, but business is growing and changing, and architecture must change with it.

Tip number 2. Do not make your client panic. Provide information as urgent, but not as disaster. Say that you have six months to refactor, but you need to start it today.

Finally . When presenting your decision, try to educate people, not blame. Remember that when blaming people you will encounter resistance from them. You should look for ways to solve problems, not the culprits.

Finally

Refactoring is expensive and hard to sell to business
Architectural refactoring is not only a technical problem, it still needs to be sold to a business
Remember the benefits of refactoring to your business.
It’s always easier to sell small refactoring, but often than large, but once

You can find more articles on architecture and architecture soft skills on the original resource.

Good refactoring to everyone!

We sell Architecture Refactoring to a client or what is the problem of developers