This article was originally published on bmf-tech.com.
In many cases, strategies and tactics are not clearly defined. This may be due to a lack of recognition of their usefulness and necessity.
Some might say, "If I have time to write a strategy, I'd rather be working," or "Even if I write it, no one will read it." However, proceeding without a strategy can lead to various problems.
This article organizes what happens without a strategy and when you should write one.
What Happens Without a Strategy
Proceeding without a strategy can lead to the following issues.
Ad Hoc Technology Selection
Different technologies are adopted by each team and phase. For example, Service A uses Redis, Service B uses Memcached, and Service C has a custom implementation.
As a result, skills are dispersed, and maintenance costs increase. Without a unified policy, selections are made based on ad hoc decisions.
Misguided Prioritization
Multiple improvement proposals such as "DB partitioning," "cache introduction," and "asynchronization" are discussed in parallel. However, without criteria for judgment, decisions are swayed by the loudest voices or recent incidents.
As a result, everything becomes half-baked, or the order of implementation becomes inefficient.
Means Becoming the End
"Microservices" become the goal, and the reason for doing it becomes unclear. Each team interprets it differently, with expectations like "wanting independent deployment" or "wanting to increase scalability" varying.
As a result, the granularity of division becomes inconsistent, and the expected effects are not achieved.
Postponing Debt Management
"Prioritizing feature development now" becomes the norm. Without criteria for when and which debts to repay, debts continue to accumulate.
As a result, debts exceed a critical point, leading to a rushed response. Planned repayment becomes impossible, causing a decline in development speed.
When to Write a Strategy
For medium to long-term projects of about 1 to 3 years, a strategy should be written. Even for projects of about six months, having a simple one is beneficial.
The reason is that without a policy, the architecture may waver when evolving over such a span. The aforementioned problems are more likely to occur.
Moreover, if there is a policy, it can be flexibly updated according to the situation. Changing the policy itself is not a problem. However, without a policy, it becomes unclear "what was changed." It is important to have a policy and update it as needed.
Making the Strategy Work
Writing a strategy is meaningless if it doesn't function. Here are some points to prevent it from becoming a mere formality.
Use as a Basis for Decision-Making
Refer to the strategy in actual decision-making. By making it a habit to ask, "Does this align with the policy?", the strategy functions as a criterion for judgment.
Review Regularly
Situations change. The strategy should not be fixed but reviewed and updated regularly. Reflect quarterly or when there are significant changes.
Share with Stakeholders
The strategy is not just for the person who wrote it. Sharing it with stakeholders and having a common understanding helps prevent the team's decisions from wavering.
Conclusion
Proceeding without a strategy leads to issues such as ad hoc technology selection, misguided prioritization, means becoming the end, and postponing debt management.
For medium to long-term projects of about 1 to 3 years, a strategy should be written. Even for projects of about six months, having a simple one is beneficial.
To make the strategy work, it is important to use it as a basis for decision-making, review it regularly, and share it with stakeholders.
Top comments (0)