Шаломович Максим Алексеевич
ИТ-специалист, по образованию - специалист по информационной безопасности автоматизированных систем. Работал разработчиком программных средств ИБ, специалистом по ИБ и ИТ-управлению (ITIL, COBIT), технологическим консультантом в процессах внедрения и (или) создания ИТ-систем. Последние годы работаю системным архитектором, участвую в проектах создания программных систем в роли архитектора и (или) технического эксперта. Кроме непосредственно hard-skills-деятельности (анализа и проектирования) помогаю организовывать совместную работу аналитиков, архитекторов различного уровня и разработчиков, выстраивать коммуникации и немного облегчать тем самым жизнь менеджерам.
System decomposition or "well, let it be integration subsystem!..."
I often ask analysts who are writing requirements documents do not create any "subsystems" or "services" just for requirement grouping purpose. I tell them such a thing makes undesirable design constraints, confuses stakeholders (especially business), and this is generally not a very useful approach. But from the other side, they are doing it anyway.
So, if you cannot break the revolution - you should lead it. I'll share my personal experience and knowledge about functional decomposition and the consequences of such decisions. Besides, I'll give you some advices and questions you shall answer before the creation of a new "user interaction subsystem".
Architecture and analysts: how to live with it?
How does the architecture hold sway over an analyst's work? Is there any difference when you are describing requirements for a monolith or a microservice? Which questions should be answered when you hear "Well, we'll put it in the cloud"?
As a person who is responsible for system architecture, I will try to answer these questions and describe my personal point of view about different ways of system analysis for different architecture patterns.
Analysis and design stories: how an analyst and an architect built a system together
Very often It happens that software system development process looks like the following chain: "analyst create specification (a.k.a. SRS or FSD) - developer creates code - repeat until the production software is ready". We put an architect in this process not even beside but in the middle. During this talk, we will discuss:
1. How and why we did that.
2. Which problems were led but which were solved.
3. How we solved the ones which were led.
The talk will be interested for an audience including all IT persons (analysts especially) who involved in the custom development projects where developers don't read specifications, analysts don't understand developers, the architect draws presentations and swears at everyone, and a manager "can't hold a candle to" and doesn't understand when this stops.
Architect in software custom development
Who are we? - system architects!
What do we want to do? - to design systems architecture!
When? - as often as possible!
...But there is a problem here - not everyone understands what it is and why it is necessary.
During this small talk, we will give you a brief review of our understanding of who we are and what kind of task we should solve within the custom development projects.