Меня зовут Максим Шаломович. Я работаю (периодически) ИТ-архитектором или человеком с шильдиком «архитектор» и иногда «решалой» всяких технических и организационно-технических приколов. Поработал и разработчиком на C/C++, и аналитиком интеграций, и внедренцем, и еще кем-то, но остановился в итоге на ИТ-архитектуре во всех её проявлениях. Люблю потрындеть с кем-нибудь что-то обсудить, кого-то чему-то полезному - по-возможности - научить.


Канал завёл для потока ИТ-шных мыслей - буквально, как записную книжку "саморазвития", площадку для публичных (насколько они могут быть публичными) высказываний и "жилетку» для нытья по ИТ-индустрии, в которой в разных качествах существую уже 17 лет. Ну и может ещё для чего интересного, не хочу себя ограничивать😂

Могу быть грубоват, не обладаю пиететом к авторитетам и чинам, но обладаю критическим мышлением. Могу шутить на странные темы, но конечно никого не оскорбляю / не призываю / не дискредитирую.

Всё, что пишу, отражает мою персональную точку зрения, а не точку зрения текущего или прошлого или будущего работодателя

З.Ы. Канал - это «локальный междусобойчик», записная книжка, которая скорее всего интересна не массовому читателю (по крайней мере, пока), а нескольким заинтересованным)) Этих же заинтересованных на свой взгляд добавляю, если вам не кайф, то можно выходить из канала без проблем, я не обижусь))) Если хочется «поделиться с друзьями, кому могло бы тоже быть интересно» - желаение странное, но реализуемое, ссылка есть😂

В телеграм-сообществе одной известной аналитической тусовки в очередной раз крутили тему «что делает аналитик» (есть в айтишечке такой прикол, когда роли раз в несколько лет «познают себя» и сталкиваются с кризисом самоопределения). И в ходе обсуждения возник вопрос, который условно можно сформулировать так: как некто (аналитик, архитектор, Папа Римский) правильно выбирает техстек или решение? Мол, когда автор вопроса в силу «зелёности» задает такой вопрос, получает ответ «не парься, это работа архитекторов».

Почему вопрос в целом справедливый, и в чем тут проблема, если начать на этот вопрос отвечать?

Совершенно справедливо, что некоторые люди с шильдиком «архитектор» превратили свою работу в своего рода искусство, которое «идет от сердца». Поэтому при попытках эту работу масштабировать через обучение и развитие новых будущих людей с шильдиком «архитектор» закатывают глаза, рекомендуют прочитать 100500 книг от Библии до «Капитала», поработать лет 40-50 во всех ролях, «и тогда может быть тебе повезет и ты поймешь…».

Правда в том, что никакие архитекторы никакой магией не владеют, и концепции принятия решений - вещи вполне осозноваемые и развиваемые. Проблема в другом.

Попытка пойти в это дело «от задачи» - это почти всегда провал, потому что в принятии решений важно не само итоговое решение и не алгоритм выбора «кафки-х**вки» вместо какой-то другой техноерунды, а важен процесс выбора и учет различных элементов контекста (да, тут будет любимое «зависит от контекста»)

Мы тут на конференциях уже который год трындим про это. Мол, дорогой юзернейм, хочешь выбрать базу данных или способ интеграции или состав микросервисов или на какой стул сам сядешь, а на какой техлида посадишь - пожалуйста, только будь добр совершить вот такие «ритуалы», пообщаться с такими-то и такими-то группами людей, аргументировать (хотя бы для себя) плюсы-минусы, задокументировать это всё в ADR хоть на полстранички без картинок - и не забудь еще свою фамилию в графе «Автор» вписать, чтобы если что, тебе премию выписали или леща - как пойдет. И тогда всё будет.

Странное дело, но такая диспозиция резко сокращает количество желающих принимать решения «просто так».

А то насмотрятся своих блок-схем от Яндекса в стиле «если у вас данные в табличечках, то берите посгрес, если в файликах - берите монгу, если хочешь идти - иди, если хочешь забыть - забудь» и потом системы проектируют

Сегодня "зависаю" на одной околотехнической конференции по близкосмежной специальности. Чувствую себя недовольным мудаком.

Вот приходят люди, воодушевленные, рассказывают, как сделали что-то классное и полезное (в основном, что-то про Arch as a Code, ArchOps и все остальные стильно-модно-молодежные штуки), сделали жизнь другим себеподобным лучше, и теперь хотят, чтобы всем было так же хорошо, как им. А я, циничная гадина, думаю о том, что:
🔹 сколько и кому это стоило
🔹 что было до всей этой красоты и, если ничего не было, то как-то же без этого всё и работало, а если было, то почему решили "выкинуть старое плохое и сделать новое хорошей"
🔹 а самое главное - нет ли ощущения, что все эти ArchOpsAsCodeWithRespectYoMazafaca как вещь в себе - облегчают деятельность, которую все "облегчатели" сами себе и выдумали, и никому она на самом деле не нужна

С другой стороны большинство докладчиков - инженеры, которых эти вопросы обычно не парят, а их компании - интернет-магазины и торговые площадки (угадайте название с двух букв). С 2017 года на таких конференциях про технические "практики" ничего по составу спикеров особо и не изменилось, ну разве что сервисы онлайн-знакомств пропали

С третьей стороны есть ощущение, что доклады/ рассказы в стиле "мы сделали вот такую штуку" как правило и должны такое двоякое чувство вызывать. Конкретный чужой результат без контекста переносится очень плохо, да и сам по себе результат (конкретное решение) не так важен, как опыт его создания (почему сделали так, а не иначе, какими вопросами задавались).

Поэтому мне и интересно и слушать, и делать доклады/ митапы/ круглые столы, где обсуждаются практики, особенно в контексте их выработки и применения. Потому что кажется, что практики более универсальны и применимы к опыту каждого слушателя, в отличие от демонстрации результатов. Демонстрация - это больше к достижениям народного хозяйства

Что вижу на "инженерных" конференциях:
🔹 как мы распиливали монолит (зачем-то)
🔹 как мы построили себе обвес для процесса анализа/ проектирования/ документирования, чтобы сделать этот процесс легче (в условиях, когда зачастую и "старый" процесс никто не выполнял и финансировать не хотел)
🔹 "вот есть такая прикольная штука" (нейросеть пишет такие доклады всё лучше и лучше)

Что бы я с удовольствием послушал (или пообсуждал):
🔹 как строилась реальная стратегия замены/ развития легаси-систем в ландшафте: как (и зачем) пересаживать на новую платформу, как управлять доработками "и там и там", как обосновать затраты на то, чтобы получить то же самое, что и было, но возможно даже еще хуже, чем было
🔹 как финансировался Inner Source или внутренние продукты/ платформы с разными бюджетами/ командами/ стримами/ трайбами/ любой другой выдуманной хернёй
🔹 как реально внедрялся/ обновлялся какой-то инженерный процесс (анализ, проектирование), не в чистом поле, не самым умным пацаном на районе и не усилием воли генерального директора

Я што, многого прошу!?🥺

Читаю (а если быть точным, то перечитываю) "Понедельник начинается в субботу" Стругацких. Словил много флешбэков из реальности. Почему-то раньше книга не вызывала таких эпичных ассоциаций.

Моей первой работой по специальности было научно-техническое предприятие в моем родном городе. Вышедшее фактически из центрального НИИ моей отрасли (спецсвязь) где-то в девяностых, оно к началу моей работы в нем (2007-ой год) ещё сохранило свой научный флёр - по крайней мере, как я это себе тогда представлял. Арендованный этаж в здании старого и почти закрытого к тому моменту НИИ (другого, не того, из которого вышла компания) в виде длинного коридора, вдоль которого располагались двери в комнаты отделов. Коридор заставлен шкафами с бумагами и папками (подозреваю, не имеющими к компании никакого отношения, просто оставшимися от НИИ). Каждая дверь - само собой - опечатывалась личной печатью, ключи полагалось сдавать под роспись на выходе суровому безопаснику, который сетовал, что АХО даже не может закупить в комнаты простейшие генераторы шума для защиты от прослушивания информативного сигнала. Отдел был замкнутый, взаимодействия с другими отделами было минимум, поэтому можно было месяцами сидеть у себя в комнате, не выходя в коридор, и не знать, например, что в соседнем отделе уже полгода работает твой однокурсник. Помнится, я месяц тестировал одну написанную мною программу на непрерывную работу - рядом с моим рабочим местом стоял круглосуточно работающий тонкий сервер, а на щитке висела бумажка с просьбой не обесточивать комнату, когда уходишь домой. Помню, однажды я пришел на место и не услышал равномерного жужжания - тест сработал, программа упала. А ещё там у меня была козырная должность "инженер программист" какого-то разряда и я был сам себе аналитик, архитектор и даже технический писатель.
Приключения дежурного Саши Привалова в новогоднюю ночь почему-то воссоздали у меня в голове этот ниишный вайб. Многое там есть и от нашего "современного" ИТ, например, эксперимент профессора Выбегалло с его псевдофилософскими и популистскими рассуждениями в угоду прессе. С игнорированием неудобных вопросов, подведением результатов эксперимента под ожидания и так далее. Пару таких "философов" например от ИТ-архитектуры можно найти в одном небезызвестном чате.

Но больше всего мне понравилось это - отличный ответ на вопрос, почему мне и некоторым моим коллегам и даже друзьям до сих пор интересна моя деятельность, и мы всё ещё задаёмся многими вопросами. И из-за чего мы часто страдаем синдром самозванца, когда вокруг люди, у которых таких вопросов ноль.

"Сюда пришли люди,... которые терпеть не могли всякого рода воскресений, потому что в воскресенье им было скучно. Маги, Люди с большой буквы, и девизом их было - "Понедельник начинается в субботу"... Они были магами потому, что очень много знали, так много, что количество перешло у них, наконец, в качество"

И ещё:

"Дело в том, что самые интересные и изящные научные результаты.. обладают свойством казаться непосвящённым заумными и тоскливо-непонятными."

В одном ИТ-шном чате на свою голову ворвался в обсуждение секьюрности облаков по сравнению с «on-premise».

С одной стороны были сторонники позиции «пенсионеры-безопасники просто ничего не понимают в облаках», с другой сторонники позиции «все, кто хочет безопасность, идет в on-premise». Первый же вопрос, который, как по мне, должен возникнуть в таком споре: что такое «облако» и что такое «on-premise»?

Ведь всем (я надеюсь) понятно, что сравнивать крайности типа «своя серверная стойка на спиной и своего админа в соседнем от тебя помещении/ свой ЦОД» и «FaaS в Амазоне» довольно странно по многим параметрам. А если мы сведём облако к IaaS или PaaS в провайдере локальной юрисдикции, а on-prem к выделенным/ арендованным мощностям в локальном же дата-центре, то получим примерно сопоставимую картину.

Далее цитата (моя собсно):

ну я вот формально могу считаться пенсионером от ИБ)) ИБшное образование, полученное 20 лет назад😁 Облака в РФ фактически появлялись при мне, когда еще ИБ было более широкой областью моих интересов. Я тоже тогда цеплялся за «облака - это несекурно», даром, что альтернатива облакам тогда виделась через призму «контролируемой зоны» и прочей ИБшной догматики.

А потом пришла практика. И ИБшная, и затем - общеИТшная. До сих пор вопрос «а чем вам не угодили облака» меня занимает) Потому что КАК ПРАВИЛО мы все понимаем, что облако - это в первую очередь про модель поставки (но у ИБшника в какой-нибудь компании от слов «облако» идет пар из ушей). А зона ответственности провайдера - и граница этой ответственности по сравнению с тем, что принято называть on-premise - это как раз предмет анализа и проектирования, при чем, желательно в совокупности с анализом угроз.

Да, крайности в стиле «свой серверная стойка/ комната, к которой есть круглосуточный контролируемый тобой же доступ» - штука наверное крутая, мечта безопасника, только вот риски, связанные с внутренним нарушителем никто не отменял. Физическое хищение/ уничтожение такой серверной стойки с точки зрения анализа угроз - не то чтобы сильная редкость (мы это даже 20 лет назад изучали активно, хотя всем конечно хотелось верить в злобных хакеров, похищающих данные через наводки по проводам). А уже надежность - и связанное с этим свойство доступности, которое, как тут метко заметили - часть триады ИБ свойств информации - у такого «онпремиса» чаще всего под вопросом.

Понятно, что если мы под облаками понимаем непонятно где физически располагающуюся функцию, запускаемую по расписанию, то тут всё очевидно. Но модели PaaS или IaaS на серверах (ок, пусть выделенных) у российских провайдеров не кажутся менее безопасными, чем «собственная стойка», арендованная в ЦОД от Ростелекома на прямую🤷. Просто безопасникам хорошо бы включать анализ рисков с точки зрения угроз и модели нарушителя, только я такого, честно говоря, уже лет 5-7 в глаза не видел.

Опять же, неизбежно должны возникать вопросы, почему мы идём в облако или почему мы идём в on-prem? Какие свойства системы мы хотим таким образом реализовать? Сравнение даже «умеренных» облаков с on-prem без этого не имеет смысла.

Продолжение следует (когда-нибудь)

Вчера с коллегой на должности «Системный архитектор» обсуждали НФТ и их влияние на архитектуру, а также почему вообще этот пласт арх работы важен.

Напомню, что я считаю термин «нефункциональные требования» абсолютно отвратительным по нескольким причинам.

Во-первых, само название «нефункциональные требования» как бы противопоставляется термину «функциональные требования». В голове как стейкхолдеров, так и команды имплементаторов (аналитиков, разработчиков, менеджеров) это противопоставление работает не в пользу первых - «мы же разрабатываем ФУНКЦИОАЛЬНОСТЬ, зачем нам какие-то НЕФУНКЦИОНАЛЬНЫЕ требования?». Как следствие, ценность всех процессов, связанных с «НФТ» - выявления, анализа, проектирования и БЮДЖЕТИРОВАНИЯ - стремится к нулю. При построении плана работ и бюджетировании все уходит исключительно в фича-деливеринг, а «НФТ» остается хотелками всяких там технарей, служб эксплуатации и прочих непонятных людей, которые не про результаты, а про техническое совершенство (что - будем честны - иногда не то чтобы прям совсем неправда). Стоит ли говорить, что практика эта порочна, а выполнение всяких *-ilities обычно стоит денег и времени, в лучшем случае сопоставимых с фичами, а чаще и намного больше?

Во-вторых, создается впечатление, что «нефункциональные требования» существуют в принципе в отрыве от функциональных, что конечно неправда. Сами по себе требования «к системе в целом» - за редким исключением - не интересны, потому что «система в целом» - это непонятная сущность. А понятными и обладающими ценностью для заинтересованных сторон являются именно характеристики, связанные с функциями системы. То есть условно, мало кому интересна «надежность системы в 99,9», потому что непонятно, как проявляется надежность целой системы, а если и понятно - непонятно, какую ценность это принесет. Тогда как «надежность функции регистрации пользователей в системе - 99,9» - вполне понятная характеристика, которую и ясно, как мерять, и ясно, как использовать. В итоге «нефункциональные требования» в имеющем ценность смысле - это по сути требования к характеристикам качества функциональных требований и сценариев (повторюсь, за редким исключением, типа «архитектурных» требований, где говорится о том, как система должна быть устроена, но и они, при желании, докручиваются до характеристик качества вида «функция А должна быть отделена от функции Б»)

Именно поэтому я в своей практике стараюсь использовать вместо термина «нефункциональные требования» две категории требований:
- ограничения
- требования к качеству,

которые в составе понятия «НФТ» обычно распределяются как 20/80.

О том, почему это важный пласт архитектурной работы, на каких этапах мы работаем с какими требованиями - в следующем потоке сознания!

З.Ы. Вот тут лежит один из моих первых докладов на аналитической конференции, где я рассказывал про архитектурно-значимые требования. Вроде как рассказывал «по-простому», для аналитиков от уровня джуна. Это доклад 18го года, с тех пор я немного докрутил эту концепцию, но общие принципы, включая подход к классификации, категории и подходы к фиксации и анализу требований остались те же. Этот же доклад лег в основу воркшопа по нефункциональным требованиям, который я проводил на нескольких конференциях, а также относительно регулярно провожу в родной организации (и как раз сейчас докручиваю его до воркшопа по архитектурно-значимым требованиям, расширяя требования качества функциональными).

Продолжение потока сознания про НФТ, начало тут.

Почему же «нефункциональные» требования так важны для архитектурного проектирования, и почему анализ НФТ сложнее, чем кажется?

Первое, что приходит в голову - достаточно старый стереотип, что "аналитик работает с функциональными требованиями, а архитектор - с нефункциональными". Конечно, это сильное упрощение, исходная суть которого в том, что аналитик часто отвечает за поставку функциональных возможностей продукта/ системы, а архитектор - за внешнее и внутреннее качество. И это качество определяется в том числе потребностями разных категорий заинтересованных лиц:

- "имплементаторов", то есть команд разработки, внедрения и поддержки/ эксплуатации. Здесь в полный рост встают такие требования, как наблюдаемость (observability), ремонтопригодность (maintainabilty), модифицируемость (modifiability), а также запланированные решения по доступности/ надежности (reliability), масштабированию для производительности (scalability/ performance) и пр.
- "лиц, принимающих решение", то есть людей/ организаций, которых в первую очередь интересуют бизнес-перспектива использования продукта или системы - возможность развития функциональности (те же modifiability), непрерывность бизнеса (за счет reliability и scalability)
- "остальных заинтересованных лиц", в том числе разных архитектурных комитетов со своими "техрадарами", специалистов ИБ со своими сертифицированными во ФСТЭК версиями и пр

Примечание:

Классификация заинтересованных лиц честно подрезана из Practioner's Approach to Development Enterpise Architecture Following the TOGAF ADM, который Open Group постоянно перемещает и то выставляет в открытый паблик по ссылке, то дает скачать только с отжиманиями через учетную запись.

Поэтому требования ко всем этим характеристикам качества надо честно собирать и анализировать - и в идеале с пониманием, как эти характеристики можно (или нельзя) обеспечить. Частая схема "копипастим требования из шаблона или другого ТЗ" не канает, так как вообще не отражает реальные потребности (за редким исключением ситуаций, когда эти требования заранее проработаны, хорошо классифицированы и действительно отражают необходимое и достаточное качество. Более того, те самые "заинтересованные стороны" чаще всего сами не очень представляют, что им надо, и формулировать требования им надо помогать. А для этого нужны и хорошие коммуникативные навыки, и хард скилы в этой области.

Ну и второй момент не такой очевидный. Так как "нефункциональные требования", строго говоря, не существуют в отрыве от "функциональных" и не несут ценности сами по себе, то и выявлять функциональные требования без связанных "нефункциональных" не сильно правильно. Конечно это не значит, что для каждого сценария и каждого ожидаемого поведения надо определять его доступность, производительность, возможность внесения изменений и прочее (хотя это было бы неплохо), но для многих ключевых поведенческих сценариев, особенно тех, которые определяют саму суть продукта (собственно это и есть архитектурно-значимые функциональные требования) - точно стоит. Кроме того есть пласт требований, которые исторически не подлежат "нормальной" классификации, например, требования к интеграции и требования к ИБ. С одной стороны это требования к функциям, с другой - к определенным качествам продукта.

Так что ношусь я с этими "нефункциональными требованиями" и пытаюсь внушить коллегам, командам и заказчикам, что "не всё так просто"

Вроде пока получается

Занимался тут некрофилией поиском старых презентаций на диске и нашел презентацию по декомпозиции систем, которую делал для аналитической конференции, кажется, году эдак в 2019 (возможно, раньше). Спустя шесть лет какие-то концепции поменялись, но непринципиально, поэтому считаю материал всё еще полезным. Поэтому, если темой интересуетесь, рекомендую посмотреть.

А сам, пожалуй, реанимирую-ка этот материал для будущих обучающих активностей…