Comments 48
Если на вопрос "зачем нам архитектор" дать ссылку на эту статью - то вопрос решится сразу. Но - в пользу того что архитектор не нужен.
Я рад что помог вам добавить определенности в этом вопросе. Вполне может так быть, что для вашей ситуации и контекста он и правда не нужен
Архитектор как фасилитатор у команд. Очень классная и дорогая елочка на зеркале. Если он не выводит команду на самостоятельное принятие решений и формирование реализуемых концепций то грош ему цена. Команда всегда сильнее, умнее и качественнее одного человека.
Артем, уточните плз какую мысль вы имели в виду? По моему опыту именно архитектор часто фасилитирует межкомандное взаимодействие, позволяя им договориться до решения в рамках "многокомандной" задачи. И здесь как раз в крупных компаниях это довольно острая проблематика. Если мы говорим про фокус внутрь команды - тут опять же про какого архитектора мы говорим? Солюшн скорее может посоветовать какие-то решения в части ньюансов реализации, но команда однозначно больше в контексте и примет в среднем лучшее решение.
я прямо именно так и написал "Архитектор как фасилитатор у команд". Есть уровень решения (на земле) и тут архитектор тоже должен построить конвейер взаимодействия с экспертами не местах. К сожалению, чаще всего это происходит иначе. Болезнь башни из слоновой кости косит наши ряды особенно у неофитов которых вдруг назначили архитекторами, но не объяснили что есть такая вещь как польза.
На уровне кроссдоменного взаимодействия тоже работает не всегда, мы же понимаем что есть жизнь и продакты сегмента КиБов легко шлют на*ер все мнения корпоративной архитектуры компании.
Архитектура — это не про бетон и кирпичи. В ИТ фундамент можно переложить, и часто это дешевле, чем жить в кривом «здании».
А часто - дороже....
Предварительная оптимизация - абсолютное зло. Месяц трахаться с кодом, чтобы потом просто его выкинуть. И так на каждом проекте, на котором пытаются оптимизировать при недостаточном понимании, как это будет связано между собой. В 95% случаев нет разницы в оптимизированном и не оптимизированном коде для заказчика. И таких проектов тьма. Бизнесу не интересны ваши оптимизации. Ему нужен продукт, который понравится. Даже, если код не оптимизирован.
Именно поэтому в России практически нет международно успешных проектов. Долго, дорого и концентрация не на продукте, а на коде.
Именно поэтому в России практически нет международно успешных проектов.
Вы уверены что их нет? И прям точно знаете что причина только в этом? Может быть есть какие то исследования, подверждающие дефективность российских разработчиков?
Ему нужен продукт, который понравится. Даже, если код не оптимизирован.
Вот только проблема в том что через пол-года когда стоимость изменений этого кода достигнет космических значений, ровно тот же самый заказчик будет спрашивать "а что так долго"? "Почему заранее не предусмотрели?" и в конце скажет что не готов тратить на рефакторинг потому что ему надо бизнес показатели улучшать и "придумай что-нибудь".
Вот только проблема в том что через пол-года когда стоимость изменений этого кода достигнет космических значений
или не достигнет тк бизнес свою гипотезу пропилотирует и решит что результат не тот что нужен для продолжения.
мы кмк смешиваем PoC и MVP. Часто у "бизнеса" есть ожидания что после успешного РоС его можно развивать дальше. По моему опыту это приводит к огромным проблемам с развитием этого функционала
на стадии MVP есть код. В чем противоречия? Этот код должен быть обязательно развиваемым как решение. Тут тоже нет противоречий. Но этот код должен обеспечить уровень качества достаточным что бы переход от MVP к разработке не приводил к переходу от agile к водопаду как часто бывает. И не требовал построения космического корабля на старте. Если архитектор не может сбалансировать эти два требования возможно он так же профнепригоден
Если проект требует серьезных изменений через пол года и не в состоянии развиваться ещё лет 5 без увеличения затрат, то это плохо спроектированный проект. Оптимизации тут вообще не при чём. Лучше проектируйте.
"Предварительная оптимизация - абсолютное зло." Полностью согласен. Еще и оптимизация на сервисах не несущих значимой прибыли для бизнеса. Есть огромное число проектов которые делают ради проектов а не ради клиентов.
"Краевые эффекты" конечно бывают, но в данном случае мы их не рассматриваем, считая априори что доработки были заранее оценены по продуктовым метрикам типа CIR и принято решение что делать "выгодно". На практике, если не брать регуляторку, я очень редко встречал команды которые из года в год делают убыточные проекты
Миф 6 - «Архитектор должен писать код»
Все что нужно знать о статье.
С таким же успехом, можно сказать что композитор не должен играть на инструменте, фитнес-тренер не должен иметь хорошую форму и т.д.
А что тогда архитектор должен? Широкими мазками обозначить: "эта штука делает то-то, а эта то-то и между ними ходят такие-то данные" ?
Это работа бизнес-аналитика, а не архитектора ПО.
Вы очень упрощаете работу архитектора. Например сейчас я описываю документ "Концепция интеграции". Его появление связано с тем, что в компании появилась шина данных. И я именно, что широкими мазками объясняю как будет работать шина, как с ней будут работать другие системы, кто к кому будет подключаться, какие данные будут передаваться, как будет работать мониторинг и т.д.
И на этом моменте мне абсолютно плевать что за системы будут с шиной работать и какой стек технологий используется, этому документу плевать даже какая будет использоваться шина.
Очевидно, что стек любого ещё не выбранного документа я не знаю, но описать документ могу. А вот отдать его написание бизнес-аналитикам невозможно, они далеки от ит, чтобы принимать такие решения.
И этих решений сильно больше, чем кажется.
. И я именно, что широкими мазками объясняю как будет работать шина, как с ней будут работать другие системы, кто к кому будет подключаться, какие данные будут передаваться, как будет работать мониторинг и т.д.
И на этом моменте мне абсолютно плевать что за системы будут с шиной работать и какой стек технологий используется, этому документу плевать даже какая будет использоваться шина.
Читал подобные документы. Ценность их отрицательная. Потому что дьявол в деталях. Вы просто переписываете для топов статью из википедии под названием "ESB".
Удивительно, что отрицательная, а не нулевая, но ок.
В моём случае никто из топов и не посмотрит на документ. Это документ для разработчиков, чтобы они понимали что делать, для лидов команд, чтобы могли контролировать разработчиков и для аналитиков, чтобы могли понимать "как с этой фигнёй работать".
Ради интереса зашёл на вики на страничку про esb. Она ни разу не отвечает на вопрос "а как конкретно эта штука должна работать" не говоря о том, что в компании бывают нюансы, которые меняют способ её использования, а значит какого-то единого стандарта не существует.
Поэтому могу сказать уверенно, если я не напишу этот документ, проект внедрения шины будет провален и пользы от её использования компания не увидит.
кому станет легче от вашей концепции? какую бизнес-пользу она принесет?
Несколько десятков систем, несколько сотен интеграционных потоков, впереди проекты по замене устаревших систем на новые. Если не написать этот документ, то каждая команда, делающая проект, выполнит интеграции по своим правилам, реализует мониторинг так, как посчитает нужным. После этого поддержка огромного зоопарка разных интеграций будет дороже. Если мы сейчас сформируем общие механизмы, которые будут использоваться в разработке новых интеграций, то уже начиная со второго проекта, разработка, касающаяся интеграций тоже станет дешевле.
Итого, если коротко:
Единый подход - проще поддерживать. Быстрее скорость реакции техподдержки на инциденты
Более быстрая поддержка = более дешевая поддержка, поскольку нужно меньше специалистов
Более дешёвая разработка за счёт переиспользования общих модулей в новых проектах и на сопровождении
у вас компания не в чистом поле стоит. Оценивать нужно разницу с существующим решением. А не архитектурные кричалки использовать. Единая концепция интеграции может привести к тому что у вас потом будет департамент поддерживающий эту интеграцию как единая точка отказа (у них есть свой капасити) и удорожание всех решений за счет накладных расходов на унификацию интеграционных подходов.
Ну да, не в чистом поле. В будущем будет реализовано несколько проектов, которые заменят старые системы на новые. То есть новые интеграции нужно разработать и поддерживать независимо от способа реализации. Интеграции не потребуют новых отделов поддержки, так что здесь точно не дороже.
А унификация подходов (использование готовых механизмов для упаковки сообщения в новый формат, заполнение заголовков единой процедурой, единый механизм передачи сообщений, единый механизм разбора сообщения, единый механизм квитирования при получении, единый способ мониторинга, который не нужно разрабатывать) сделает разработку, начиная со второй только дешевле, а не дороже
а раз старые интеграции не будут выведены в один день то у вас уже образуется зоопарк из того что вы сейчас считаете целевым решением и существующими подходами ) Ну и где тут простота поддержки? напоминает классический труд про управление вселенной. Скорее всего существующие решения по интеграции вам придется переделывать целиком это приведет к каскадному росту стоимости проектов. Либо все так же будут продолжать поддерживаться два, а когда вы уволитесь то и три и четыре подхода.
Давайте чуть упростим ситуацию для общего понимания.
Есть системы А, Б и В. Каждая сейчас интегрирована с каждой. Как? Хрен его знает, потому что делалось это несколько лет назад, документации нет. Доработка существующих интеграций - это сложно, потому что нет прозрачного понимания как оно должно работать, сопровождается ошибками. Поддерживается как-нибудь. Обычно по принципу работает - не трожь.
Решено, что системы А, Б и В будут заменены отдельными проектами на А1, Б1 и В1 соответственно. Это даёт кучу своих плюсов, расширение функционала и т.д.
Но помимо этого мы внедряем кшд. Здесь логика простая, кшд позволит сильно упростить дальнейшее сопровождение интеграций.
Каждую систему будет заменять своя отдельная команда внедрения, а значит и способы интеграции, которые они будут использовать на проекте, скорее всего будут отличаться. Кому-то нравится использовать сервисы интеграции, кому-то веб-сервисы, кто-то использует XML, кто-то json. У кого-то инициатором обмена будет шина, у кого-то система, кто-то отправляет квитанции о получении сообщений, кто-то считает это лишним. Думаю вы понимаете о чем я говорю, здесь вариантов много.
Если мы просто скажем этим командам "интегрируйте через шину", то они сделают как-то по-своему, а потом нам нужно будет поддерживать эти разные реализации. И поддержке на каждом этапе нужно сначала понять о какой системе/интеграции идет речь, а только потом, получив ответ как она должна работать, решать возникающие проблемы. То же самое при доработке интеграций.
Если же описать концепцию, то она ответит на все эти вопросы, а значит все реализуют одинаково. В концепции будет описано какие механизмы должны быть переиспользуемыми.
И вот сейчас, опять же для простоты есть 6 потоков. При внедрении шины потоков станет больше. Но потом их количество будет уменьшаться, точек мониторинга будет становиться меньше и после внедрения всех систем и после устранения прямых интеграций между системами их сопровождение станет сильно легче и комфортнее.
Давайте упростим ситуацию, потому что, похоже, она действительно сложна вам для понимания.
Начну с вашего утверждения о какой-то мифической интеграции между системами — интеграции, о которой никто не знает, как она работает, но почему-то она работает. У этих систем что, нет собственных команд развития? Это уже многое говорит о "здоровье" ИТ-подразделения. Руководитель такого ИТ, на мой взгляд, профессионально непригоден и с точки зрения собственников должен быть заменен. Ему нельзя доверять ничего, кроме замены картриджей в принтере — это максимум его компетенций.
Дальше вы говорите, что существуют две системы, А и Б, между которыми уже построено пять разных интеграций в рамках предыдущих решений. Появляется новая концепция и еще одно решение, которое предполагает новый принцип интеграции. Но предыдущие пять интеграций никто не отменяет, просто добавляется шестая, по другому принципу. Это «зоопарк» — и именно он порождает интеграционный технический долг, тормозит agility, создаёт нерасторопность в будущем.
По оценке LinkedIn, в технологической сфере средняя продолжительность работы сотрудников составляет примерно 2–3 года, а среди разработчиков и инженеров — около 2 лет.
Когда жизненный цикл системы измеряется десятками лет, а сотрудники остаются в проекте в среднем 2 года, велика вероятность, что инициаторы стратегии интеграции никогда не увидят её результаты. Это создает долговую нагрузку, осложняет сопровождение, снижает скорость адаптации и повышает риски переноса знаний.
Возникает вопрос: зачем всё это? Какую пользу бизнесу и бюджету ИТ даст очередная концепция?
Если каждое новое решение строится на принципе «сложнее просто потому что так требует концепция», без пересмотра предыдущей логики, интеграционный зоопарк становится нарастающим долговым обществом: предыдущие связи остаются, добавляются новые, а компетентность команды — неумолимо меняется.
Ну вот вы себе придумали кучу дополнительных условий, а на основе этого говорите, что никакая концепция не нужна. При замене системы с А на А1 очевидно, что все интеграции, касающиеся этой системы, нужно переписать. С Б на Б1 аналогично и так далее.
Так что вопрос как переписывать:
1. Как пойдёт
2. По правилам
Если внедряется кшд, то интеграции тоже переписываются. И да, само собой, что оставлять старые интеграции, добавляя новые - это бред. Вот только этого никто делать и не собирался. Так что вот именно в этой ситуации описание концепции, описание правил разработки, формирование регламентов максимально своевременно и оправдано
Тот факт, что мы продолжаем обсуждать проблемы, характерные для позапрошлого века, был очевиден уже из самой концепции шины данных. Замечу, что ещё в начале 2000-х годов я получил один из первых сертификатов Oracle по данной тематике.
Говорить сегодня о замене одной информационной системы на другую — по меньшей мере странно, учитывая, что подавляющее большинство компаний уже давно внедряют микросервисные архитектуры, а многие даже начали отходить и от них, переходя к новым парадигмам построения ИТ-ландшафта.
Я нигде не утверждал, что ИТ-концепции в принципе не нужны. Моё замечание касалось лишь того, что апеллировать к этим подходам как к некоему фундаментальному, монументальному достижению — когда соответствующие решения давно описаны, реализованы и внедрены в индустрии — выглядит, мягко говоря, не вполне современно.
С таким же успехом, можно сказать что композитор не должен играть на инструменте, фитнес-тренер не должен иметь хорошую форму и т.д.
Нет, с тем же успехом так сказать нельзя, это манипуляция чистой воды. Абсолютно разные предметные области.
На мой взгляд тема стоимости слабо раскрыта - только общими словами.
Возможно в тех 20 мифах есть что то про конкретные цифры пользы для бизнеса?
Миф 4, или «И без архитектора справимся»
это вовсе не миф. Большинство проектов и ИС внутри компаний не требуют никакой архитектурной поддержки. Ну если конечно команду набрали из вменяемых людей. Архитектура нужна там где есть нагрузка и ответственность. А если это сервис аффектит на сегмент 0.000001 выручки то зарплата архитектора это и есть удорожание проекта
Артем, безусловно у каждого свой опыт и контекст. Я работал в основном в "кровавом энтерпрайзе", и помимо критериев нагрузки и влияния на результат, есть еще важный критерий "кроссдоменности" задачи, с которой даже вполне вменяемые команды справляются сильно дольше в отсутствии архитектора. И чем более "микросервисный" и сепарированный ландшафт, тем значимей роль архитектора и для конкретных задач, и в целом для "всея-ИТ" метрик типа TCO, T2M и т.д.
ну мы то все остальные в основном по детским садам работали. Поэтому да, примем ваши утверждения на веру. У меня есть утверждение генерального конструктора одного из банков побольше чем ваша организация раз в 20: корпоративная архитектура это когда не найдешь кто за что отвечает. Я вам привожу конкретный пример с сильным доменом которому наплевать на все идеи корпархитектуры. И у вас нет ни одного шанса сломать их родмап для включения в беклог хотя бы одной фичи которую их бизнес считает не целевой.
Миф 6, или «Архитектор должен писать код»
И это не Миф. Человек не связанный с ИТ не понимает обычно что все изменения нужно вести через череду POC кроме того доказывая что ситуация классифицирована верно иначе речь будет идти об огромных затратах на техдолг. Поэтому - кто не программирует тот не айтишник
Ну и дела у вас во ВсехИнструментах. Архитекторы пишут код, но и без них все справляются. И никто не трогает рабочее. Как ты только выдерживаешь:-)
Мне кажется сначала надо явно сказать про каких архитекторов мы в статье говорим, потому что мифы будут на каждом уровне разные. А так в начале сказали про виды архитекторов и потом все равно всех смешали.
Спасибо за ОС, я вообще хотел +/- про всех, но видимо не совсем удачно) можете плз тыкнуть где именно смешение есть на ваш взгляд?
Наболевшие п.4 - тут наверно стоит указать, хотя бы, какой именно архитектор нужен для какого уровня проекта, нам на одном из проектов не хватало архитектора бд, пришлошь как тимлиду вывозить, в целом посыл такой - на что больше все идет когнитивная нагрузка команды, то и архитектурим(бд, сетевое взаимодействие, бизнес-логика и т.д), иначе есть риск получить вермишели, в целом с автором согласен; п.6 - не всем надо код писать, только software и devops архитекторам. Это все, конечно, мое субъективное мнение
Архитектор не должен делать то, архитектор не должен делать это... А что вообще он должен делать?
одна из главных задач архитектора — сделать принятие решений командой более осмысленным
Что конкретно это означает? У вас допустим есть десяток senior-разработчиков с опытом 10+ лет, почему их решения недостаточно осмысленные?
Мифы об ИТ-архитектуре, из-за которых ваш проект стоит дороже