Шаломович Максим Алексеевич
ИТ-специалист, по образованию - специалист по информационной безопасности автоматизированных систем. Работал разработчиком программных средств ИБ, специалистом по ИБ и ИТ-управлению (ITIL, COBIT), технологическим консультантом в процессах внедрения и (или) создания ИТ-систем. Последние годы работаю системным архитектором, участвую в проектах создания программных систем в роли архитектора и (или) технического эксперта. Кроме непосредственно hard-skills-деятельности (анализа и проектирования) помогаю организовывать совместную работу аналитиков, архитекторов различного уровня и разработчиков, выстраивать коммуникации и немного облегчать тем самым жизнь менеджерам.
Decomposition of a system in practice
A system analyst often has to be a bit of an architect, including decomposition an information system into some parts: modules, components, subsystems.
At the workshop, we will analyse what criteria and principles can be used to ensure that the chosen decomposition at least does not complicate further design and architecture, and we will work out these criteria with examples.
Something about requirements which change everything
Nowadays the software development lifecycle never stops. Customers generate new needs, analysts gather new requirements and developers implement it. In such situations, the probability that every new requirement will change an architecture increases dramatically.
We will discuss why some requirements can be implemented with two strings of code only while others lead to "Seems we should buy another 3 DB Servers"? Why some change requests are "that's OK", but others like "We'll all die!!!". Will try to understand together and discuss how to avoid it.
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.