How the lack of ready-made formats led to the emergence of an IT architects community in Kazakhstan

Complex compromises, outdated architectures, visions, non-obvious agreements with business, and the boundaries of the architect’s role are discussed far less frequently, although it is precisely these factors that most often determine the final outcome of transformations. It was this sense of a lack of open professional dialogue that sparked the story of the IT Architects community in Kazakhstan. It emerged not as an idea to create yet another format for meetings, but as an attempt to build a space where one could calmly and professionally discuss real architectural practice.

In this article, Laura Salamat, author at The Tech and founder of the community, along with Rustem Uvaliyev, explain why they felt the need for such a space, how the community was formed, and what role it plays today for the architectural market in Kazakhstan.

Laura Salamat, IT Architect and CDTO of the NNEF Public Foundation

Rustem Uvaliyev, IT Architect, Head of Digitalization at BTS

How It All Began

Laura. For me, it all started in February 2025, when I was working on developing target IT architecture for one of the industrial enterprises. It was a complex, multi-layered process involving numerous stakeholders, domains, constraints, and expectations. It was precisely at this moment that one problem became clearly apparent: even within the professional community, there is still no unified understanding of what an IT architect actually does and where their area of responsibility ends.

Architecture is often perceived as a single universal role, although in practice, it is a set of different functions and specializations. It is impossible for one person to equally be responsible for business, application, data, infrastructure, and information security architecture, yet business expectations are often exactly like that. At some point, I realized that these issues are rarely discussed publicly. These questions remain “within teams,” even though many face them. At that moment, I simply wanted to document these thoughts. Later, the idea was supported by the The Tech editorial team, and everything developed organically from there. I invited colleagues, and Rustem was one of the first to respond.

Rustem. When Laura suggested I participate in the article, I agreed almost immediately. We were not well acquainted, having crossed paths only at general expert meetings. However, the topic itself was close to me, and I had seen many of the issues raised in my own practice.

After the article was published, it became clear that the demand for such discussions was much broader. The market simply lacked a space where architects could discuss their real work without formalities and showcase-only case studies. I suggested to Laura that we try to develop this into a format of regular meetings, and it turned out that we were thinking in the same direction. Thus, from a convergence of views, the community grew.

Launching the Community

Rustem. We decided to hold the first meeting as simply as possible, without complex formats or expectations. We invited familiar architects and chose a topic that seemed basic but was, at the same time, the most painful.

We even joked that if ten people showed up, it would already be a great result. In the end, more than 60 people attended the first meeting. At that moment, it became obvious that this was no longer a one-off event, but a demand for a permanent professional space. In fact, the community was born that day; we came up with the name and created a Telegram group right on the spot.

Laura. The first meeting is still vividly remembered. We consciously chose a simple format to get acquainted and hear what requests the architects had. One participant jokingly said that he had described his work at the company and asked GPT what architectural role he actually performed, because he himself had stopped being sure about it. And in this joke, surprisingly enough, one of the most pressing problems in architecture was accurately voiced.

Companies often expect one architect to cover all domains simultaneously. At the same time, the architect’s status within the organization is often vague: somewhere they are an expert without authority, and somewhere they are a universal “person responsible for everything.” It was already clear then that this topic resonated with almost everyone and that a space for such a discussion was truly necessary.

Laura. We immediately agreed that this would not be a place for sales, promoting tools, or building personal brands. We did not want the meetings to revolve around technologies or specific products, because architectural problems are much broader.

At one of the meetups in 2025 dedicated to data, one of the speakers said that it was the first time he had seen such a meeting format where no one tried to sell anything or collect contacts to return later with a commercial proposal. For us, this was another confirmation that we had chosen the right direction from the start.

Rustem. One of the key principles for us is the absence of hierarchy. It is important to us that architects come not to perform or listen, but to talk to each other, get to know one another, and calmly discuss work situations. This approach naturally led to the format of our meetings. We mainly discuss meetup topics with community members based on their real requests and current tasks. This allows us to keep the meetings practical and lively.

By the same logic, we often invite community members themselves as speakers. Many have strong expertise and experience that is important to share. As a result, our meetings turn out to be more lively and substantive.

What Topics Shape the Community’s Agenda Today

Rustem. We do not form the agenda around individual technologies or trends. We are interested in architectural issues that remain relevant regardless of the current market cycle.

The focus of our meetings is on making architectural decisions under conditions of uncertainty, managing complexity and accumulated constraints, distributing responsibility between architecture and business, and the long-term consequences of architectural decisions for the organization. The format is no less important. We consciously move away from lectures and presentations and work with meetup topics by analyzing real case studies.

Community Members

Rustem. Not only architects with different levels of experience and from various industries—banking, industry, telecom, education, IT—attend our meetings, but also analysts, tech leads, and business owners. Some have many years of practice behind them, while others are just beginning to form their role as architects, but their requests are largely similar.

Most often, these are already participants of our community. They come to listen to case studies, discuss interaction with business and teams, and understand how to make architectural decisions under constraints. For many, it is important simply to check in with colleagues and ensure that they are not the only ones facing similar questions.

Initial Results

Rustem. For me, the most valuable result is the people and the alignment of values. It is these professional connections that eventually turn into joint projects and real changes. I would like to increase the value for community members through more useful content and new formats, as well as expand the geography—there are already requests to hold meetings in Almaty.

Laura. For me, the community has become a point of professional support. There is now an understanding that there are people nearby with whom one can discuss complex cases, launch joint projects, and find solutions. This significantly changes the perspective on the profession.

Where the Community Is Heading

Laura. Looking at a five-year horizon, I do not view the community as an organization that needs to be scaled quantitatively. I see the community as a stable professional environment where a common understanding of architectural approaches, responsibility, and the maturity of the architectural function is formed. Currently, the market still lacks a clear understanding of why business needs IT architecture and what managerial role it should play. It is fundamentally important to me to change this perception, primarily on the business side. Architecture is often perceived as a supporting IT function or a set of formal artifacts, whereas in practice, it determines the stability of solutions, the manageability of changes, and the organization’s ability to develop.

Through the community, I want to gradually build this understanding, showing architecture as a tool for making managerial decisions rather than as an abstract technical direction. This, in my opinion, is the long-term value of the architectural profession for business.