How to decide on architecture for your company, with no fear — part 1
Do you feel you are using too many frameworks, tools, and long development processes? Well, you’re not alone, and it’s time to break the circle.
As a tech consultant for companies, I’m often asked to make order in technological chaos.
In one of my recent projects, the client asked me to decide on a tech architecture for the frontend developers and get them aligned after a long period when there were no clear definitions.
Already on the first day on the job, I realized that the task is not easy, and is not only technological.
So come join me on my six-month journey of making order in a technological mess. I will show you how to involve people to be part of the process and make changes that will lead to a clear and ordered process.
Why is tech alignment important?
In a world endlessly full of development approaches, it is very easy to get confused and not make decisions. In such a situation, each developer or development team chooses the approach that is convenient for them, and the result of this is a lack of sync between the developers and the teams, no knowledge sharing, no cooperation, and worst of all — a technological gap is created between the teams, products, and bugs keep appearing.
What to do before starting to research technologies?
Just before we start researching what technologies exist on the market, and determine what the technological stack will make up the architecture, it is important to stop, take a breath, and check some things that are just as important as the choice of technologies itself.
First of all, it is important to decide what is our ultimate goal? What is our goal in deciding on architecture?
It is easiest to determine the architecture and that’s it. To establish a fact. But in this way we determine an architecture that is good for us. It is important to remember that technological architecture should be right for the organization, not us. And this is our goal, our starting point.
When we think about what is right for the organization, we think about what is right for those who will use our architecture decisions, and how it will affect the day-to-day work.
In technological architecture, our target audience is the programmers. The decisions we make will affect the way they work, the way they will plan their tasks, write code, especially if it is a technological change from the one that currently exists in the organization.
Such a change for everyone can be accepted in two ways: for the better, or for the worse.
Those who love technologies, are not afraid to make changes. They will welcome the decisions that will be made in the architecture, and will assimilate the changes with enthusiasm.
On the other hand, there will also be employees who fear such a change. They know their code, work in a familiar and comfortable way for them, and may express opposition to the new architecture.
It is important to accept the objection with understanding, and also to listen to it. The comments that will be received can help to get a more accurate picture of what is happening in the organization in general, and with the developers in a specific way.
The developers are the “customers” of the architecture, so it is important that they will feel part of the change.
In order to make the process of assimilating the architecture more positive in the future, it is very important at this point to recruit the right key people for the process.
Key people are anyone who can influence the process: development managers, product managers, tech-leads, and of course the developers themselves.
In the process I led, I identified who the development managers are who understand the need for technological change, who the developers are the opinion leaders in the organization, and I created a common circle of thought that will help me understand what the needs of the organization are, where the pain points are in development, and what is important for me to take into account in the decisions I make.
It was important to me to have a variety of voices in the thinking circle, that there would also be those who would oppose the changes I intend to make. The objections are an opening for a good and correct conversation, which will help both me and the developers to reach a mutual understanding that a change needs to be made, but also how to do it properly so that I get cooperation and support from the developers themselves.
After all, in the end, we are all human, and it is important that we listen to each other and work together in the organization, that’s the only way we will get the best results for the process.
In the next article, we will continue the journey of choosing the right technologies, how to write a correct and clear architecture document, what do we do with this document in general, and what are the next steps after the decisions are made.
Stay tuned…
That’s all for today, let me know what you think. See you on part 2.
Happy coding! 🤓
