Записки системного архитектора

Прямо отозвалось... Давно заметил, что что гибкие методологии сами по себе без правильно подготовленных людей не работают. Но для неподготовленных людей могут долго создавать иллюзию, что все идёт нормально.

Как часто мы слышим фразы типа "так делать неправильно, а правильно вот так"? И я как-то задумался, а что такое "правильно"? помните "что такое хорошо и что такое плохо" Михалкова? Там все четко расписано - вот так делать хорошо, а так плохо. Жаль, что в мире ИТ архитектуры нет такого мануала. Тут принято говорить, что все "зависит от контекста". Но почему-то часто, когда приходишь в команду с таким контекстно-зависимым решением, то через раз слышишь, что так неправильно...

Мне видится, что правильные или неправильные решения могут быть в математике, когда есть строгие и четкие правила построения выводов и вычислений, когда любое рассуждение формализовано и воспроизводимо, т.е. можно гарантированно на тех же входных данных получить тот же результат. Наверное, в ИТ можно поступать так же, т.е. составить алгоритм принятия решений, накидать в него все возможные входные условия и формально прийти к решению. Но что-то мне подсказывает что это нереально. Во-первых, входных условий невообразимо много. И даже если вы думаете, что учли все, всегда есть еще одно. Методы принятия решения на одних и тех же входных данных тоже разные, опираются на разные принципы, зависят от состояния и стадии ЖЦ. Зависят от внешней реальности, которая вообще часто непредсказуема и носит "полувероятностный" характер.

Вспоминается фраза одного из сейлов - Мы выиграем этот тендер с вероятностью 90%, но вероятность вот вот тех 10% - примерно 60%.

В общем, я к тому, что использовать слова "правильно" или "неправильно" по отношению к архитектурным решениям кажется не очень корректно, лучше использовать более конкретные эпитеты. Например использовать слова "обосновано/не обосновано", которые описывают степень обоснованности, мотивированности выбора того или иного подхода в решении. Может быть "нестандартное" решение, если оно не похоже на общепринятые подходы, "рискованное", если оно несет в себе больше рисков, чем ожидается, ну и т.п.
#мысливслух

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

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

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

Мартин Фаулер, международный эксперт по программной инженерии, начал свою публичную просветительскую деятельность с книги Analysis Patterns 1997-го года.

При этом как ни удивительно, книга интересна и актуальна до сих пор и для разработчиков и для архитекторов и для системных аналитиков.

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

Андрей Гордиенков решил исправить это досадное обстоятельство и подготовил собственную версию перевода.

https://habr.com/ru/articles/872598/

Вступление
1.1 Концептуальные модели
1.2 Мир шаблонов
1.3 Шаблоны в этой книге
1.4 Концептуальные модели и реинжиниринг бизнес-процессов
1.5 Шаблоны и фреймворки
1.6 Использование шаблонов

Часть 1. Аналитические шаблоны
2. Ответственность
3. Наблюдения и измерения
4. Наблюдения для корпоративных финансов
5. Обращение к объектам
6. Инвентаризация и учет
7. Использование моделей учета
8. Планирование
9. Торговля
10. Производные контракты
11. Торговые пакеты

Часть 2. Поддерживающие шаблоны
12. Слоёная архитектура для ИС
13. Фасады приложения
14. Подходы для моделирования типов
15. Шаблоны ассоциации
16. Послесловие

Часть 3. Приложения
А. Техники и обозначения
В. Таблица паттернов
C. Краткая справка по диаграммам

Друзья!
Спасибо что читаете этот канал, и мы встречаем этот год вместе! 🎊🎉
Поздравляю всех с наступающим новым годом! 🎄🎄🎄
Пусть все неприятности останутся в уходящем 2024-ом, а новый год принесёт драйв, новые интересные вызовы и достижения!😜

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

Короче говоря, принцип-то в основе лежит простой, но его практические применения в каждом отдельном взятом случае могут сильно отличаться. Но это уже другая история.

все еще #знакомство

продолжение следует? 😉

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

Самое сильное воздействие на меня оказали книги "Lean Startup" Эрика Риса про итеративный поиск места продукта на рынке, "4 шага к озарению" Стива Бланка про Customer Development и формирование понимания потребностей клиента и "Построение бизнес-моделей" Остервальдера. Будучи программистом мне казалось, что достаточно сделать хорошо работающую программу, а остальное приложится само. На деле оказалось, что работа программистов, безусловно, важна, но, как не противно было это осознавать, с точки зрения бизнеса глубоко вторична. Программа интересна лишь постольку, поскольку она помогает решать чьи-то проблемы, приносит кому-то какую-то понятную пользу, измеримую хотя бы в деньгах. А работа программистов с точки зрения бизнеса - это всего лишь вынужденные расходы. И, грубо говоря, если расходы меньше доходов (как меры пользы) - то это хорошая работа, а если больше - то плохая :) Хотя, конечно же, все гораздо сложнее, зависит от стадии развития продукта, зрелости рынка и т.п.

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

#знакомство Продолжение

Следующий виток расширения мировоззрения пришёлся на 2010-е.

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

Первым краеугольным камнем в фундаменте изменений стали книги по теории ограничений систем, начиная с почти развлекательных трех "Целей" и "Критической цепи" Голдратта, продолжая более серьезными книгами Уильяма Детмера и Лоуренса Лича. Теория ограничений произвела на меня глубокое впечатление, сильно изменила мой способ восприятия и понимания мира, научила обращать внимание на причинно-следственные связи, задавать вопросы "почему?" и "зачем?".

Вторым камнем для меня стали взгляды Насима Талеба. "Черный лебедь" и "Антихрупкость" хорошо легли на удобренную теорией ограничений почву. Пришло понимание, что просто делать свою работу хорошо и правильно - недостаточно для успеха, что ничего не существует само по себе, в отрыве от окружения. Миром правят случайности и вероятности, а наши возможности по прогнозированию сильно ограничены. Мало вкладываться в работу над понятными вещами, важно также, по "принципу штанги", защищаться от потенциально неизвестных событий. Теперь я всегда повторяю своим детям мысль, что если не хочешь ПОТОМ разгребать последствия неожиданных СЛУЧАЙНОСТЕЙ, лучше СПЕЦИАЛЬНО СЕЙЧАС что-то делать, чтобы снизить их вероятность или меньше от них зависеть. Банальный пример для детей - если ты специально всегда готов к уроку, то тебе неважно, когда учителю придет в голову дать контрольную. Более прикладной пример из программирования - если СНАЧАЛА реализовать простую обработку ошибок/исключений "вообще", которая для любой непонятной ошибки будет выдавать какое-то осмысленное, но главное - детерминированное поведение (запись в лог, сообщение об ошибке пользователю и т.п.), то тебе неважно, какие ошибки случатся ПОТОМ. Когда все неизвестные варианты "прикрыты", можно спокойно делать частные, улучшенные, специализированный обработчики конкретных ситуаций.

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

————————-
продолжение следует...

Записки системного архитектора pinned «А давайте знакомиться. Я тут подумал, каналу скоро два года, а я так и не собрался представиться и рассказать о себе. Исправляюсь. #знакомство Здравствуйте. Меня зовут Борис Романов и сейчас я алкоголик архитектор. Когда-то давно, еще в 90-х, я был программистом…»

А давайте знакомиться.
Я тут подумал, каналу скоро два года, а я так и не собрался представиться и рассказать о себе.
Исправляюсь.

#знакомство

Здравствуйте.
Меня зовут Борис Романов и сейчас я алкоголик архитектор.

Когда-то давно, еще в 90-х, я был программистом, сочинял программы на тему управления документами, всякие архивы, документообороты, формочки, поиски т.п. Писал на С++, мне очень нравилась выразительность этого языка. Но, надо признать, временами получалось достаточно громоздко.
Позднее, в 2000-х появился .NET и C#, код стал лаконичнее и выразительнее. Особенно, когда появились лямбды, LINQ и прочие функциональные приблуды.
Вообще, мне очень нравиться программировать. это прикольно и интересно. Я когда-то (надо же, уже 12 лет назад!) даже писал про это пост на хабре.

Процессы разработки были тогда еще дикие, неформализованные. Роли аналитиков, продактов просто не существовали. В команде был руководитель проекта, разработчики и (иногда) тестировщики. Про скрамы и водопады никто не слышал. Люди просто собирались и работали. Помню, когда появился трекер багов - bugzilla - так это было просто откровение :).

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

Так что к началу второй декады 21 века я постепенно переквалифицировался из программиста в странный гибрид архитектора и менеджера. Читал книжки про UML и управление проектами, пытался осмыслить вероятностную природу рисков. Даже статью тогда написал про использование MS Project для управления проектами по разработке ПО.

Тогда я впервые стал задумываться, что перед разработкой неплохо бы сначала понять, а что же именно нужно запрограммировать. Позиция "давайте сразу нормальные требования, будет вам нормальная программа" очень удобна, но в реальной жизни работает плохо. В том смысле, что требования все равно приходят ненормальные и все равно многое приходится переделывать.

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

—————————————————————————
😉если вам интересно, то продолжение последует...

Еще одно огромное спасибо коллегам из @Systems.Education, которые помогли по материалам доклада подготовить статью.
Так что для тех, кто не любит смотреть видео, теперь есть лонгрид на хабре про аналитические модели.
Для текстового изложения получилось, наверное, немного скомкано. Не уверен, что для начинающих будет понятно назначение каждого типа моделей... Но тем, кто уже походил по граблям, надеюсь, будет полезно. Так, в свое время для меня просто открытием стали доски Story Mapping... Если будут вопросы - не стесняйтесь задавать в комментариях. Можно тут, можно и непосредственно на хабре.

Геннадий Круглов в своем канале рекомендует начинать с другой книжки про системное мышление - «Азбука системного мышления», Донелла Медоуз. Тоже хорошо, кстати, можно и с неё начать.

P.S. Вспомнил еще книжки про устройство бизнеса. Мне прямо очень хорошо зашли романы Артура Хейли, который живописно описывал работу отеля, аэропорта, завода, клиники. Очень впечатляюще описывается сложный механизм работы большой и сложной системы, состоящей из множества элементов.

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

Подытоживая, я бы рекомендовал начинать путь к архитектурной работе со следующих шагов:
1. Прочитать несколько книг, расширяющих мышление за границы технических вопросов.
Мой список must read:
- Цель. Э.Голдратта.
Если зайдет первая - то прочитайте 2 и 3 части, они тоже интересные. Но 1 - обязательно.
- Искусство системного мышления. О'Коннор Дж., Макдермотт И.
- Антихрупкость, Н.Талеб

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

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

3. А вот тут, после получения базовых метанавыков мышления можно уже изучать профессиональную литературу по архитектуре. Благо, выбор немалый. Ну, т.е. теоретически можно с этого начинать, но, мне кажется, без первых двух пунктов эти книги покажутся невыносимо нудными и бесполезными :).

А параллельно накапливать технические скиллы и опыт. Старайтесь, изучая или читая про очередной фреймворк или СУБД, обращать внимание не только какой он сам по себе быстрый, надежный, удобный и т.п. а насколько он полезный для решения тех или иных задач. В чем сильные или слабые стороны, по сравнению с аналогами. Пригодится, когда нужно будет обосновывать то или иное архитектурное решение.

И вот, наконец-то, мы подобрались к ответам на исходный вопрос - как и чему учиться.

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

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

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

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

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

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

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

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

Или другая, не менее частая история.

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

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

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

Рассмотрим, к примеру, задачу вывода нового продукта на рынок. Все мы считаем, что делать надо хорошо, а делать плохо - не надо. И потому нужно делать программы с использованием современных фреймворков, применять правильные паттерны декомпозиции и абстракции, а всяким легаси-системам место на свалке.

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

И вот тут очень нужен архитектурный взгляд, способность смотреть на программный продукт в динамике разработки и с учетом перспектив его развития. Выбрать, на чем можно сэкономить на ранних этапах, но сделать это так, чтобы получившийся продукт можно было постепенно развивать и улучшать, причем без полной переделки, не теряя темпа разработки. Т.е. нужно принимать технические решения не только "здесь и сейчас", но обязательно с учетом контекста, стратегических планов и перспектив.

Итак, "я разработчик, хочу расти в архитектора, куда смотреть, что изучать?"

С точки зрения здравого смысла ответ на этот вопрос очень прост. Чтобы стать архитектором, нужно научиться делать то, что делают архитекторы. А для этого сначала придется разобраться, чем же, все-таки, занимаются архитекторы. А дальше уже можно будет подумать, как этому научиться.

Со стороны разработчиков часто может показаться, что архитекторы - это такие странные люди, которые приходят со своими странными и не всегда понятными идеями и говорят, как нам надо жить и что мы должны делать. И это иногда, наверное раздражает. Чем же занят архитекторы и откуда у них берутся идеи и почему компании стремятся их завести?

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