While a tech radar might seem like a tool primarily for a manager or, at best, an architect, but in our practice, it has proven to be extremely useful for other team members, starting from junior analysts.

One key use of a tech radar is during interviews when a candidate asks, ‘What’s your tech stack?’ You can either list something like ‘Back-end in Java, use Airflow as ETL, PostgreSQL for storage, ClickHouse in some places, and considering Greenplum,’ or you can simply show the tech radar. In terms of speed and clarity, there’s no comparison.

On one hand, analysts rarely choose the tech stack. On the other hand, there are cases where they might influence it. If there’s a need to move some technology from assess to trial or even to adopt, a visual representation of technologies can help in finding the right solution.

The importance of quickly assessing the potential of enhancements to a component and having up-to-date knowledge on available technologies is is difficult to overestimate.

Every company keeps some data, but often no one has a complete picture of where and what data. It is not uncommon for teams to be unaware of what metrics their neighbours are collecting. 

Also, information about stored data may be needed to meet compliance requirements, secure storage, etc. 

Therefore, it is more important than ever to implement the DataGovernance best practices. Their most popular description is DAMA-DMBOK2, which contains 11 sections worth paying attention to. 

In my talk, I will focus on one of them - Metadata and describe how you can implement the Data Catalog in your company, fill it, implement an updating system, and some technical solutions applicable to this. 

As a result of such implementation, there will be up-to-date information about where and what datasets are stored, the ability to search through them when it is necessary to calculate some metric, and an understanding of where what and with what effort to protect.

In this talk, we will consider how to evaluate the investment attractiveness of projects to automate something using the example of MLOps implementation (although, in principle, this way of modelling is suitable for almost any DevOps activity). 

We will discuss what the revenue and expense sides are, how to get these figures, and, most importantly, what to do with them afterwards. 

The talk looks like a product talk, but it is not quite so - firstly, the task of gathering the requirements needed for such calculations often lies on the analyst, and secondly - for infrastructure projects the analyst may well be the person who will make the decision when justifying a particular technical solution.

The talk will focus on how the work with data is transferred to end-users of this data in practice — product managers, financiers, backend developers. 

I will talk about our experience of transition from DWH development with ETL and reports/dashboards/cubes by data engineers to datalake, where data engineers are responsible only for infrastructure, control procedures and problem-solving, end-users write queries (literally as queries or through visual builders like PowerQuery/PowerBI), and the ability to add new data types to the warehouse is available to any product team.

My talk will cover requirements gathering in data science projects, which can vary widely - from simple ad-hoc queries to complex researches involving different math tasks and, especially, machine learning tools. It will be based on my experience in this area. I will speak about things you need to get from your customer, how to measure work results, and how to enrich data when dataset that you have is not enough to get good results.

While requirements are gathered, it is possible to get into situation where product owners wants very flexible system and can't describe all of the logic. However, this flexibility shouldn't affect fault tolerance and performance, and, at other side, development should be completed at reasonable time. Among other, there is Business Rule approach to build such system. But flexibility has other side - the price of error in rules can lead to significant loss both in terms of performance and service logic.

Where to find a balance between flexibility, performance and fault tolerance? Where requirements gathering should be started? My talk will cover this and some other aspects around building of BRE systems.