Architecture refactoring and any other design and project refactoring is a painful topic. Refactoring profit is obvious for us – technical guys like architects and developers, but hard to sell and prove this idea to the client. The main reason: we technical guys don’t know how to talk with business guys.
The main problem – communication between technical and business people. They speak different languages but want to achieve the same goals.
Benefits from refactoring are obvious for you, but not for business people. You should divide architecture refactoring 6 mandatory steps and follow this plan:
- Identify the architecture root cause for issue
- Determine what changes should be done
- Business case justification
- High-level architecture refactoring plan
- Create a timeline
- Present your case
Identify the architecture root cause for refactoring
This step is most common for us as for tech guys. Let’s look at a couple of examples.
Application build fails whenever someone commits changes.
There are a couple of reasons why it can be:
- Application components are too tightly coupled and dependent on one another
- Application components do not have the right level of granularity and isolation
- Lack of unit test
- Lack of SDLC processes and CI/CD pipelines
One more example. Application deployments take a long time. At runtime, an application has performance issues.
The root cause could be:
- It is a monolithic application a grows fast. It is getting too large for a single app
- Application too large and consuming all CPU and memory
- Application is complex and writes an inefficient way
Determine what refactoring should be done
The second step is slightly more complicated, but should not be hard for developers starting from senior level and higher. All we are good technical specialists and know what should be done. At this moment we make the common mistake and run with this proposal to the client and talk to the client let’s do it.
But we are smart architects and will follow 6 steps one by one.
Based on the previous example with a monolithic application, the decision is obvious. Split big and complex applications into smaller, independent deployable modules. It could be a movement to service-oriented or microservice architecture.
Business case justification
Let’s split these two phases: technical and business justification.
Technical justification is looking obvious for us. Splitting monolithic application to smaller services, it could be:
- Components are more decoupled
- Issues with the build not so often
- Each small service consume less memory and has better performance
- Separate services could be deployed faster and independent
Business justification – this step is very important and often skipped by technical guys. You should remember what is important for the business and driving a business. Correct – it is money!
Long story short, if your design refactoring doesn’t give any value for business, there is no sense to do it.
Based on our example, you can offer your client the next business values:
- New functionality can be delivered faster, reduce time to market
- Application quality will be better, reduce the cost for bug fixing, as a result, client satisfaction is better
- Development and deployment costs reduction
- Easier to find motivated and qualified developers
High-level architecture refactoring plan
A refactoring plan should provide clear vision and granularity. Each iteration should show architecture and design changes.
Preparing the refactoring plan you should answer the next question:
- What is the purpose of this iteration?
- What is a technical and business value for this iteration?
- How to minimize iteration duration?
Create a timeline for architecture refactoring
Very important step – invest time for this exercise. Every manager and person from the business world what to know answers on two question:
- How much?
- How long?
Try to split architecture refactoring small iterations. Each iteration should bring some technical and business values. It is hard to sell refactoring with a duration of a couple of years and millions of dollars without intermediate results.
Each phase should have a duration or range of estimates and headcount of resources. This information gives your managers a vision about refactoring costs.
You should collect measurements and KPIs before and after refactoring iteration to show improvements and benefits after each stage. For instance: measure deployment time of monolithic application before refactoring and deployment time after slitting to services.
Present your case
Before go to business, present and the validate idea with your direct manager first. Third-party validation always is good, especially if it is a business person. Probably your manager knows some business context which helps you adjust refactoring plans for the business.
You should know how to answer the classic question.
Usually, when you present architecture refactoring to the business you may be asked. Why do we need refactoring? We spent a year ago a lot of money on architecture and design and now we have issues.
The classic question has a classic answer. This solution was good enough 1 year ago, but your business is growing, numbers of users and requests are growing. Architecture should be adjusted with changing business.
Next advice. Don’t make people panic – present this with an urgency not with panic. Just deliver info that we have 3-6 months for refactoring, but should start ASAP.
Last but not least. Presenting your case educates people not to blame. Never criticize people, in this case, you can meet obstacles from their side. Use this opportunity to educate people and show benefits and business values. Don’t look for the guilty, look for opportunities.
Summary
- Refactoring is expensive. It is hard to sell it business
- Architecture refactoring not only technical task it is also about selling your idea
- Remember about business value and justification
- Easies sell small refactoring often than big once time
More articles and pieces of advice about soft and hard architecture skills.
Happy refactoring!
