Мама, кажется я архитектор


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


    Кто такой архитектор?


    Погуглить на эту тему может каждый самостоятельно. Я постараюсь не быть кэпом и отражу сущность архитектора под необычным углом. Лично мне нравится шуточное определение этой роли:


    Архитектор — человек, который способен любому разработчику в команде аргументированно доказать, что его мнение ничего не стоит.

    или:


    Архитектор — человек, который лучше других знает когда нужно уходить из проекта.

    Хотя оба определения шуточные, но они демонстрируют пару ключевых способностей этой роли:


    • Широкий кругозор с одновременно глубоким погружением в детали;
    • Способность комплексно видеть причинно-следственные связи и возможные результаты развития событий.

    За этими пунктами стоит большой опыт. Можно ли обойтись без десятка(ков) лет в профессии, чтобы стать архитектором? Можно. Так же, как стать сеньором С++ через пару месяцев. Все зависит от человека, его способностей и самокритичности.


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


    Если мы возьмем команду примерно равных по опыту разработчиков, кто из них станет архитектором? Тут обычно два сценария:


    • каждый сам себе архитектор;
    • архитектор тот, кто может внятно доносить свои мысли и преимущества своих решений.

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


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


    Поэтому, к важным качествам архитектора относится и:


    • Высокий эмоциональный интеллект.

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


    Что должен делать архитектор?


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


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


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


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


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


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


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


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


    Архитектор обязан делиться своим опытом и уметь “переваривать” чужой. В команде всегда найдется кто-то с интересным опытом. К сожалению, обычно, этот опыт имеет узкий угол обзора его предпосылок. При выборе стека разработчик может сказать:


    • А давайте все сделаем на React! Мы так делали и у нас все получилось!

    Сомневаться в этом нет причин. Но это не повод делать также. У проекта на котором он работал есть свои исторические корни и проблемы. Весьма вероятно, что React имеет минусы, о которых разработчик или умалчивает, или не знает.


    Умалчивать разработчик может ненамеренно. Возможно он исключительно React использовал до этого. Ему не с чем сравнивать. Случается и обратное. Например, на рынке разработчик React выше оплачивается. На прошлом месте он завидовал коллегам пишущим на React. Но шанса изменить стек не было. Т.е. разработчик имеет исключительно шкурный интерес.


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


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


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


    И конечно, архитектор обязан создавать системы с бизнесом, для бизнеса и ради бизнеса.


    Чего не должен делать архитектор?


    Самое главное, что не должен делать архитектор — допускать демократию.


    Т.е. количественный метод принятия решений. Где любой в равной степени может воздействовать на выбор.


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


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


    Второе по важности — недопустимо дистанцироваться от бизнеса и разработчиков. Иногда, так хочется пожить в своем идеальном мирке, где все понятно и логично. Но, жизнь сурова. Бизнес стремится развиваться. Нужно уметь слушать идеи бизнеса и понимать вектор их развития. Закладывать в архитектуру концепции, которые позволят решать задачи, еще несформулированные бизнесом.


    Держи друга близко, врага еще ближе, а с разработчиком нужно быть одним целым.

    Какую бы классную архитектуру не наваял архитектор, если разработчик не видит в ней ценности, он ее похоронит.


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


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


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


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


    Где искать архитектора?


    У нас в компании встал вопрос поиска архитектора на проект. Как водится нужно описать вакансию. Требования относительно очевидны:


    • Широкий, актуальный и релевантный опыт в ИТ;
    • Лидерские качества;
    • Развитые софтскилы.

    Предлагаю эксперимент — закройте рукой слово “архитектор”. Какая роль рисуется под этими скилами? Скорее ИТ-директор или CTO. И это вполне справедливо. Более того, вероятна ситуация, когда от архитектора требуются гораздо более развитые скилы из этого перечня. А разница заключается в обязанностях.


    Для архитектора:


    • Создавать и развивать архитектуру систем;
    • Участвовать в разработке процессов компании;
    • Наставничество;
    • Разработка стандартов.
    • ...

    Для директора:


    • Работа с подрядчиками;
    • Управление бюджетом;
    • Управление и развитие команды;
    • Обеспечение непрерывности процессов;
    • ...

    Что мы видим? Очевидно, что архитектор и руководитель расходятся в цели существования.


    Типичный юный ИТшник видит перед собой карьеру: джун->мидл->сеньор->тимлид->CTO. Но где-то на третьей ступени он начинает понимать, что, что-то идет не так. И уже на последнем — теряет самореализацию в разработке. Он перегружен административкой. Забыл когда в последний раз код писал.


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


    Путь архитектора это иной, весьма интересный путь. Я бы сказал, это правильный путь ИТшника. Не менеджера, а именно ИТшника. Который хочет иметь все более серьезные профессиональные вызовы. Он имеет возможность самореализации каждый день на всем карьерном пути.


    Так где искать архитекторов? Мне кажется: среди счастливых профессионалов или внутри несчастных менеджеров.


    Вместо заключения


    Предлагаю пообщаться на тему необходимости архитектора в команде. Как вы себе представляете его роль? Сталкивались ли вы с его необходимостью? Возможно напротив, он вам мешал? Видите ли вы себя архитектором в перспективе? Хотели бы вы поменять путь менеджера на путь архитектора? Сделало бы вас это счастливее?

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 50

      +13
      Вы забыли самое главное.
      Архитектор должен писать код. Например, половину времени.
      Писал код год назад не работает. Смотреть на код только через код ревью тоже не работает.

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

        Я бы сказал, что он должен это делать как процесс поддержания навыков. Самостоятельно.
          +5
          Самостоятельно писать продашен реди код в свободное время? На постоянной основе? У вас странные вкусы.

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

          Никто не говорит что обязательно каждый день по 4 часа. 2-3 дня в неделю, неделю через неделю, месяц через месяц если совсем никак.
          Время выделяется руководством. Это обязательная часть работы. Чтобы чуство реальности не терять.
            0
            Продакшен реди код это сильно круто. У архитектора должен оставаться конфликт интересов с этим самым кодом. Я предполагаю участие архитектора в ключевых основах системы. Например базовые классы проекта или его структура. А развитие уже идет разработчиками.

            В наших проектах для этого выделена область «core». В нее доступ имеет core-team. В том числе и архитектор через нее «видит» проект. Бизнес-логика же реализуется путем наследования от классов core.

            Документация по API также развивается архитектором. Описанный контракт уже реализуется разработчиком.
              0
              Продакшен реди код это сильно круто. У архитектора должен оставаться конфликт интересов с этим самым кодом. Я предполагаю участие архитектора в ключевых основах системы. Например базовые классы проекта или его структура. А развитие уже идет разработчиками.

              Так в доведении до прода весь сок.
              Чтобы понять как все это ложится и переписывается при пятом изменении желаний менеджеров.
              Как все это мониторится, отлаживается, саппортится.
              Насколько часто происходят вообще неведомые вещи.
              Насколько приятно писать, отлаживать и катать готовый код.

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

              В наших проектах для этого выделена область «core». В нее доступ имеет core-team. В том числе и архитектор через нее «видит» проект. Бизнес-логика же реализуется путем наследования от классов core.

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

              Документация по API также развивается архитектором. Описанный контракт уже реализуется разработчиком.

              В век микросервисов АПИ это примерно все.
              Публичное АПИ? Конечно, все только спасибо скажут. С ним море проблем и согласований всегда.
              А вот апи между парой соседних микросервисов, которое еще и меняется в процессе разработки раз 5 фиксировать это такое себе. Поправить по паре строк и там и там, убедиться что никто больше не задет и всем станет лучше. Часто ведь бывает.
              У вас там точно нет рядом второго «теневого» апи? Которое разработчики сделали чтобы работало, а не чтобы правильно было?
                0

                Коротко я ответить я тут не смогу. Нужно развернуто. Уже завтра отпишусь. Мы много обсуждали те вопросы, которые Вы подняли.

                  +1
                  Так в доведении до прода весь сок.

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

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

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

                  Если архитектор должен писать прод реди код, то он обязан следовать установленным стандартам. Очевидно, что он превращается в разработчика. И выполнять свою функцию далее не может.

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

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

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

                  Выглядит очень странно. В проекте есть код который нельзя менять, но который надо использовать.

                  Я не говорил, что нельзя. Я написал, что менять его может core-team. Это не какие-то люди в закрытом помещении на 45 этаже. Это твои коллеги за соседнем столом. И если тебе в голову пришло что-то поменять, и ты видишь, что это область core, то ты должен обратиться к ним — core-team.

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

                  Но чаще всего, если это действительно нужно, делается все тот же классический pull-request, о принимает его core-team.

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

                  В век микросервисов АПИ это примерно все.

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

                  Он может контролировать этот процесс через pull-requests. Всегда найти документацию на контракты. Всегда построить интеграционные связи. Без этого никуда.

                  У вас там точно нет рядом второго «теневого» апи?

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

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

                  Надеюсь, смог ответить на все вопросы.
                    0

                    Вот вы создали область участия. Она не идет в прод. Точнее идет, но руками обычных разрабов. Те кто ее делал понятия не имеют насколько это удобно.
                    Они также понятия не имеют насколько больно выполнять их же правила разработки. Для решения надо просто писать код в продакшен. Eat your own dog food.


                    Надо поменять вот тут кусочек. Вместо типичного: ПР и на ревью устроена бюрократия.
                    Разработчики они часто нелюдимые и не хотят ни к кому подходить. А вы заставляете. Мне бы было просто неудобно третий раз идти и говорить что вот тут плохо. Надо переписать. Люди имеют привычку забывать, откладывать, делать потом. То есть то что мне нужно еще неизвестно когда прорастет в мастер.
                    Все таки стоит сделать рядом свое. Так даже быстрее будет. И всем хорошо сделаю. Надо поменять? Меняйте смело!


                    Вы слишком не доверяете свои разработчикам. Архитектура и ревью архитектуры это хорошо и правильно. Допустим на задачи от пары месяцев работы. А вот спускаться на уровень "этот код тебя нельзя трогать, его можно трогать только специальным людям" не стоит. Обязательное код ревью на этот код от сеньеров покрывает все задачи невнесения говнокода в общие места. И не вынуждает никого ни о чем просить или ждать.

                      0
                      Те кто ее делал понятия не имеют насколько это удобно.

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

                      Ключевая причина — противодействие хаусу. Т.е. когда любой в команде, вдруг, считает что нужно половину кода переписать. Потому, что он не хочет у кого-то что-то узнать. И думает, что легче все самому наваять.

                      А это приводит к дублированию кода. К лапше. Вечному рефакторингу и растущему техническому долгу. Этими процессами нужно управлять.

                      Вы слишком не доверяете свои разработчикам.


                      Мы доверяем своим разработчикам настолько, что в любой момент времени, любой разработчик может встать и сказать:

                      — Архитектура говно! Давайте что-то с этим сделаем!


                      Это приведет к совершенно конкретным активностям.
                      1. Архитектор подключится к вопросу;
                      2. Выслушает претензии;
                      3. Если претензии основаны на недостатке информации — доведет ее. Проверит, что источники получения информации достаточны. А если нет, доработает.
                      4. Если претензия обоснована, будет запущен процесс корректировки архитектуры.


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

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

                        Вы сами сказали что они не пишут код в прод. Окуда им знать?
                        Причины могут быть любые сделать что угодно. С какой-то стороны это будет хорошо и удобно. Но опять таки вероятно что мнение разработчика пишушего в прод будет другим. И не очень лестным.

                        — Архитектура говно! Давайте что-то с этим сделаем!
                        Это приведет к совершенно конкретным активностям.
                        Архитектор подключится к вопросу;
                        Выслушает претензии;
                        Если претензии основаны на недостатке информации — доведет ее. Проверит, что источники получения информации достаточны. А если нет, доработает.
                        Если претензия обоснована, будет запущен процесс корректировки архитектуры.

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

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

                        Вы мои слова ровненько подверждаете.
                        Писать код неудобно и неприятно? Отклонено.
                        Ваш велосипед заменяем вот на эту типовую библиотечку с нормальной лицензией? Отклонено.
                        Приходится городить бойлерплейт когда его можно избежать? Отклонено.
                        Можно просто сдедать в разы проще? Отклонено.
                        Стиль кода устарел лет на 10? Отклонено.
                        Все. Доводов нет.
                          0
                          Разговор заходит в тупик.
                          Вы сами сказали что они не пишут код в прод.

                          Кто они? Где сказал?
                          Прыгать на людей которых поставили выше тебя?

                          Архитектор не находится выше разработчика. Он — партнер.
                          Будем реалистами. Кому это надо?

                          Тем, кто болеет за результат.
                          Ну его. Больно надо. Я тут код пишу, а не политикой занимаюсь.

                          Это выбор каждого.
                          Костылим или акккуратно пишем сбоку.

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

                          Для этого есть процесс качества. Возникший инцидент приведет к разработчику. Если еще на тестировании не будет выявлен.
                          Вы мои слова ровненько подверждаете.

                          Где?
                          Писать код неудобно и неприятно? Отклонено.

                          Вы точно внимательно мой пост читали?

                          Создается впечатление, что вы упорно транслируете свою модель поведения в роли архитектора. Оно так не работает. Мне казалось, что в статье я достаточно четко выразил мысль о формировании доверия между разработчиком и архитектором.

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

                          И тот факт, что лично Вы в это не верите не меняет ситуации.
                            –1
                            Talk is cheap. Show me the code
                            Eat your own dog food
                            Вы нарушаете основополагающие принципы.

                            Кто они? Где сказал?

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

                            Архитектор не находится выше разработчика. Он — партнер.

                            Партнер это тот кто вместе со мной хотфиксит релиз.
                            Тот чей код я ревьюю, а он мой ревьюит.
                            Тот, кто вместе со мной ночью откатывает внезапно упавший прод.
                            Тот с кем мы гадаем о причинах неведомой фигни по графикам. И потом переделываем эти графики, потому что они ничего не показывали на самом деле. Объяснять почему нужны не те, а вот эти графики? Увольте. Я даже простыми словами не расскажу что на них. Для менеджеров есть простые графики, которые им понятны. Вот на них пусть и смотрят.
                            В конце концов тот кто просто пишет код. Пилит фичи, рефакторит, сажает баги и фиксит их, знает о всех типовых проблемах и костылях.

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

                            У вас еще и ревью не все подряд проводят? Новичков и джунов исключаем по понятным причинам. А остальных то за что? Им же этот код поддерживать, дописывать и дежурить с ним. Им и оценивать насколько он хорош.

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

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

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

                            Я даже хитрые варианты с «развернуть микросервис вот на этой виртуалочке с именем dragons-lives-here и дергать его через воон тот балансер в конфиг которого годами никто не лазил туда можно любой роутинг запихать» не предлагал. Только самые очевидные.

                            Обычно вообще хватает простого невыполнения того о чем они говорят. Киваешь головой, соглашаешься и делаешь как хочешь. Они все равно не полезут код смотреть. Не их дело руки марать и читать тысячи строк кода новой фичи. А ведь в этих тысячах строк еще разобраться надо. Этот навык тоже быстро утрачивается. А дедлайн вон он. В прод надо. Срочно.
                            А потом: Это же уже продакшен код. Работает. Проблем не вызывает. Вот если соберемся рефакторить или переписывать из-за изменений задачи тогда и разбираться будем что там.

                            И тот факт, что лично Вы в это не верите не меняет ситуации.

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

                            Они могут быть отличными техническими менеджерами, знать много баззвордов. Причем на самом деле знать, а не на вики о них читать. Могут уметь договариваться с бизнесом о желаниях разработчиков, могут наоборот договариваться с разработчиками о желаниях бизнеса. Но им нельзя лезть в то как именно будет писаться код. Это дело разработчиков, в конце концов за это разрабочикам большие деньги платят.
            +4

            Абсолютно.


            Мы пошли по немного иному пути: у нас несколько очень сильных разработчиков, и они все выступают в роли архитектора на разных участках. Часто слышен клич: «ребята, застрял, нужна свежая идея» — внутри «команды» архитекторов.


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

              0
              … и они все выступают в роли архитектора на разных участках

              Ну т.е. архитекторы есть. Сколько их это вопрос частный.
              «ребята, застрял, нужна свежая идея» — внутри «команды» архитекторов

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

              Это какие-то крайне высокоуровневые архитекторы, которые проектируют экосистемы на уровне бизнес-функций. Архитектор проектирующий систему не может не участвовать в разработке кода. Элементарно, разрабатывая архитектуру БД он должен понимать как туда класть данные и как достать. Как сделать это быстро. И быть способным ответить на вопрос — какого хрена ты придумал?

              То же касается любого сегмента проектирования.
              Некоторые вещи имеет смысл упростить архитектурно, ради изящества реализации. Некоторые — наоборот, усложнить, ради завтрашнего дня, — но не до состояния «реализовывать три года с группой синьеров».

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


                Не получается ли, что такой архитектор будет сильно ограничен в выборе компонентов?

                Kafka/NATS/RabbitMQ/ZeroMQ… и это только очереди, с БД все еще более пестро. Разнообразные реализации edge router, ingress, serviсe mesh, logging, monitoring… Со всем не наработаешься.

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

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

                  Чуть сложнее дело со слабыми сторонами. Тут нужно уже ресерчить по практикам.

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

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

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

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

                  Для примера, в своем опыте, мне встречались такие решения как Cache Intersystems, IBM Websphere, Apache Synapse и т.п. Эти продукты завозились для решения конкретных бизнес-потребностей. Хотя эти же потребности можно было решить и более известными решениями. Но эффективность этих продуктов, на тот момент времени, оказывалась выше.
                    +1
                    У архитектора, для начала, должно быть понимание, что все существующие решения делались для какой-то благой цели умными людьми.

                    Когда он начинает проектирование, он исходит конечно из своего опыта и знаний. Но выбирает решение наиболее релевантное задаче.

                    Логично. Архитектура по сути решение набора проблем наиболее оптимальным способом с точки зрения ресурсов (денег, времени, исполнителей и т.д). Чем больше ресурсов (деньги время исполнители и т.д.) использовано в минимальном объеме (меньше денег + меньше времени + и т.д.) — тем архитектура удачнее\выгоднее.
                      +1
                      Те же очереди, классическая задача выбора решения.

                      Я пару лет назад довольно много времени потратил этот выбор. В написании кода я не участвовал, потому что еще не было кода, а «архитектуру» нужно было уже создавать.

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

                      Со всем не надо работать, надо знать что внутри, то есть алгоритмы и структуры данных. Не те, что на первом курсе, а штуки вроде MVCC, из которого вытекает vacuum, из которого вытекают интересные следствия для репликации, write amplification и т.д. Увидели MVCC и сразу знаем, что ещё идёт в комплекте, без необходимости тратить годы на освоение нюансов каждого продукта.

                +4

                Встречал два типа архитекторов:


                1. Слуга: Давайте я просто зарисую, что вы там напридумывали
                2. Творец: А давайте я все же придумаю архитектуру: но, мы обязательно будем использовать контекст, микросервисы и сделаем фреймворк для динамических типов и форм ввода. Желательно, чтобы и БД состояла лишь из 3 таблиц: две для метаданных, а одна — для значений… стойте! Давайте сделаем две таблицы! Ох, я гениален! А вы криворукие разработчики — не можете вытянуть данные из моих таблиц для отчетов!

                Есть и другие типы, но эти крайности встречаю каждый день.

                  0

                  Метко!


                  Есть у меня "один знакомый", который пошел по второму сценарию. Ну не совсем, но что-то типа ключ-значение он запилил в реляционной бд через три таблицы.


                  Для этого были причины. Корневая — исключение даунтаймов системы при изменении структуры бд.


                  Грубо говоря, колонки таблицы заменены строками. Если в схеме появляется новая колонка, не требуется изменение схемы БД. В мета заезжает новое поле. Если удаляется, соответствующее поле дизейбится.


                  Этот подход не тотальный. Т.е. касается только чувствительной области данных. Где бизнес-мутации очень высоки.


                  Этого "знакомого" часто, подчеркиваю, справедливо критикуют за нарушение реляционного принципа. Но, пока, лучшего решения предложено не было.


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


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


                  Тоже не взлетает по причине шардирования и использования оригинальной таблицы на запись в момент миграции данных.

                    0
                    Но, пока, лучшего решения предложено не было.

                    Json/xml ?

                      0
                      Не понял вопроса. В значениях полей JSON структура. Реализовано на pg. Прекрасной особенностью этой субд является способность идексировать такие структуры. Что утвердило в таком решении.
                        0
                        Грубо говоря, колонки таблицы заменены строками. Если в схеме появляется новая колонка, не требуется изменение схемы БД. В мета заезжает новое поле. Если удаляется, соответствующее поле дизейбится.


                        Это очень похоже на EAV и это очень плохая идея. В противовес этому можно сделать таблицу kv, с колонками «key: varchar», «value: jsonb»
                          0
                          Ну собственно такая таблица и есть.

                          «key: varchar», «value: jsonb»


                          Почти. Только в ней key не varchar а идентификатор типа. Типы перечислены в специальной таблице, которая пополняется/модифицируется миграциями. В ней же хранится описание типа, признаки обязательности и валидатор значения.
                            0
                            Положили в БД описание типов и валидаторов, а в коде написали интерпретатор всего этого дела. Вопрос — зачем писать такой интерпретатор и программировать на этом DSL, почему нельзя на нормальном языке все тоже самое описать?
                              0
                              В БД положены типы, чтобы компенсировать недостаток прозрачности структуры. Это нужно аналитикам, тестировщикам да и разработчикам. Когда ты пишешь запрос, ты легко можешь получить сведения о типах полей в человеческом виде.

                              Плюс к этому, это контроль консистентности структуры этого решения.

                              Валидатор это регулярка. Позволяет быстро провалидировать фактические данные в БД с целевым шаблоном. Помимо этого, участвует в генерации нотаций в формате OpenAPI.
                  +1
                  Вообще ярый противник таких должностей. Это рудименты «отсталой» российской разработки и бюрократического аппарата. Задача современного бизнеса — мотивировать разработчиков так, чтобы они «горели» проектом. Важно понять одно: если в проекте царит атмосфера стартапа (а это значит что каждый участник рискует своими финансами, впрочем как и профитами) — то сообщество команды начинает выстраиваться в саморегулируемое… и тогда «размывается» грань архитектор ты… или разработчик. В этом дух стартапа. В этом дух будущего! А должность «архитектор» придумана, как пережиток бюрократического устройства системы, когда есть некто, кто определяет курс и несёт за него ответственность. Минус подхода в том, что ответственность архитекторы в современной продакт-команде ведут как правило словесную и доказательную… они никак не рискуют финансами, и как следствие — не «живут» проектом, а превращаются в банальных менеджеров. Благо, я замечаю, что бизнес рано или поздно начинает это понимать.

                  И правильно, как сказали выше, архитектор, как правило перестаёт писать код… и превращается в менеджера. Происходит банальное управление командой на уровне слов… не вникая в детали проекта и не понимая «узких» мест разработки. И разработчики от этого, только демотивируются… доказывать словами — пустая трата времени для разработчика. А доказывать делами, тогда, когда есть кто-то, когда взял на себя обязанность «вести» проект — глупо. В общем на мой взгляд — это рудиментарная должность, которая исчезнет со временем.

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

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

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

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

                    Нужен ли тут архитектор? Да он все похоронит. Он постоянно будет зайца держать за хвост. Потому, что он понимает, что срок жизни у такого решения очень и очень краткий. Но объяснить это зайцу невозможно. Заяц не имеет тот же пул ценностей что и архитектор. Он же видит «дерево» и знает, что до него можно добежать за 10 секунд. А архитектор видит, что справа куст ракиты, слева волк, а сверху ворон. Но заяц пока молодой и не постиг боли. Он быстрый и уверенный в себе.

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

                    Как видите, в этом случае существует баланс. Стартапы не портят всякие архитекторы потому, что они туда не пойдут. С другой стороны, стартап можно испортить архитектором, если заяц раньше времени подумает, что он бык.
                      +1
                      Доля правды есть в ваших словах. Я уверен, что, к примеру в таких компаниях, как Google или Amazon — архитекторы тоже есть, и тоже двоякое мнение по поводу них у разработки) И я уверен, что у них те же проблемы… Что и у нас. Более того, после просмотра фильма Дудя про силиконовую долину я в принципе расстроился во всём :)

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

                      Я уверен, следующим этапом — будет переход к более свободному духу разработки. Свободный — это когда нет жёстких требований и жёстких указаний. Когда фриланс может быть полезнее, чем несколько архитекторов. Про то, что конкурсные основы (по типу таких, которые устраивает Паша Дуров) — принесут профита больше, чем содержание штата ну и т.д. Когда ответственность несёт команда, а не отдельные должности, и команда же и рискует, предлагает решения, самоорганизовывается… Развивать мысль далее, я не буду. Но смысл в том, что всё меняется…

                      Наверняка хороший архитектор будет в цене. Но «хорошесть» должна базироваться на фактическом опыте выполнения проектов. На том, что реально было сделано и принесло ли профит.
                        0
                        В ваших выводах наблюдается проблема первичности. Простой пример — почему деревья качаются? Потому, что ветер или ветер потому, что деревья качаются?

                        Действительно, удаленка много что показала. И хорошее и плохое. Есть такое хорошее утверждение — звездный час менеджера тогда, когда все плохо. А тут были целые недели. Многие зайцы сдохли. Быки выживали за счет жирка. Но народились новые зайцы, для которых этот «постапокалиптический» мир все, что они знают. Ладно, довольно метафор.

                        До ковида удаленка была. Но кто на нее шел? те, кто ее искал. Вопрос — зачем? Потому, что он имел некоторые цели ее получения. И в общем-то всегда они были шкурными. Удаленка не просто была, удаленщик хотел еще и быть свободным в графике.

                        Так кто ее искал? Оооочень часто люди мало организованные, ставящие в приоритеты не работу, а свои цели. Это я не теоретизирую, а лично работал с удаленными командами.

                        Что изменилось в ковид? На удаленку ушли люди которые собирались работать. Т.е. тот самый офисный планктон. И ничего удивительного в том, что он так же эффективно работал и удаленно. Совершенно ничего удивительного.

                        Теперь о том, что корпорации что-то там поняли. Удаленку рассматривали всегда. Ровно так же, из моего жизненного пыта этот вопрос всплывал регулярно. Но от него отказывались. Почему?

                        В крупной компании есть процессы, которые очень затруднительно вынести на удаленку. И это не совещания. С ними как раз все норм. Это документооборот. А также работа с персональными данными, коммерческой тайной и т.п.

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

                        Так что изменил ковид? И опять все просто. Он не дал иных путей как меняться. Все ли изменилось? Нет конечно. Огромная кипа документов ждет людей в офисах. Даже в период жесткого карантина не было тотальной удаленки. Ключевые люди завязанные на эти процессы ходили в офис. А многие процессы остановились до лучших времен.

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

                        Я взял этот пример для наглядной демонстрации того, что глубинное понимание причин является необходимым. Такая роль, хочешь или нет будет. Но ее качество может быть различным.
                          +2
                          Действительно, удаленка много что показала. И хорошее и плохое. Есть такое хорошее утверждение — звездный час менеджера тогда, когда все плохо. А тут были целые недели. Многие зайцы сдохли. Быки выживали за счет жирка. Но народились новые зайцы, для которых этот «постапокалиптический» мир все, что они знают. Ладно, довольно метафор.

                          Быки всегда выживают, за счёт жирка. И за счёт коррупции в стране.

                          Так что изменил ковид? И опять все просто. Он не дал иных путей как меняться. Все ли изменилось? Нет конечно. Огромная кипа документов ждет людей в офисах. Даже в период жесткого карантина не было тотальной удаленки.


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

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


                          Опять с этим не поспоришь. Более того, выгоду получили компании, которые завязаны на должностях, бумажной волоките и прочим коррупционным составляющим. А настоящий бизнес — «малый и средний», не зависящий от званий, выслуги лет и гособеспечений — меняет вектор бытия) Т.к. пункт выше.

                          В крупной компании есть процессы, которые очень затруднительно вынести на удаленку. И это не совещания. С ними как раз все норм. Это документооборот. А также работа с персональными данными, коммерческой тайной и т.п.


                          Всё давно решаемо. Самое главное, чтобы все это понимали. Включая людей, от которых зависит принятие решений. К сожалению, в большинстве — эти решения далеки от реальности.

                          Подитоживая: я просто высказал своё мнение. Возможно оно «недальновидное», но поживём — увидим. Ни в коим случае своими рассуждениями никого не хотел обидеть. Это всего лишь субъективное мнение. Да к тому же, возможно, неверное (ибо я не архитектор).
                            0
                            Вспомнилась шутка: «В России даже, если внедрят электронный чип, при приходе куда-то всё равно потребует бумажную копию этого чипа».


                            Хорошо, давайте другой пример приведу. Из реальной жизни. Смотрите. Трейдер. Он же через Интернет торгует? Какая ему разница откуда из дома или из офиса? Я даже больше скажу, очень многие трейдеры торгуют из дома. Роль идеально ложится в удаленщика.

                            Но, внезапно, их сгоняют в офис. Зачем?

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

                            Управляющие компании имеют каналы резервирования. И конечно, они подводятся в офис.

                            Вуаля. Российская коррупция тут не при делах. И такого, действительно много.
                              0
                              Но, внезапно, их сгоняют в офис. Зачем?

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


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


                              Абсолютно аналогично с юристами и их бумагами — просто регулятор требует, чтобы определенные вещи не выходили из офиса.

                              +1
                              Подитоживая: я просто высказал своё мнение. Возможно оно «недальновидное», но поживём — увидим. Ни в коим случае своими рассуждениями никого не хотел обидеть. Это всего лишь субъективное мнение. Да к тому же, возможно, неверное (ибо я не архитектор).


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

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

                              С Вашей подачей все нормально.
                        +1
                        А должность «архитектор» придумана, как пережиток бюрократического устройства системы, когда есть некто, кто определяет курс и несёт за него ответственность. Минус подхода в том, что ответственность архитекторы в современной продакт-команде ведут как правило словесную и доказательную… они никак не рискуют финансами, и как следствие — не «живут» проектом, а превращаются в банальных менеджеров. Благо, я замечаю, что бизнес рано или поздно начинает это понимать

                        Архитектор это инструмент понижения бизнес рисков с помощью которого решаются конкретные проблемы: Координация направления решения, поддержание базы знаний решения (ведение проектной документации), аудит реализации решения.
                        Кто-то должен дать банальный ответ на вопросы: а сколько будет стоить в разработке? а сколько будет стоить в эксплуатации, а сколько будет стоить в сопровождении? а какой жизненный цикл этого решения? И такие данные должены быть по нескольким вариантам решений, поскольку бизнесу надо планировать свои финансовые потоки и риски. Разработчик этим будет заниматься? Проектный менеджер? у них просто нет таких компетенций.
                        Некоторые компании реализуют что-то вроде «архитектурного комитета» — в котором несколько архитекторов по нескольким направлениям. Небольшие компании могут делать что-то вроде внутреннего публичного рецензирования архитектурных решений.
                          0
                          С этим я не поспорю. Я к тому, что для того, чтобы архитектору дать временную оценку и все прочие оценки, ему надо иметь чёткое представление о том, как это лучше сделать. Зачастую, этих представлений нет в связи с ограниченностью времени архитектора, которое он тратит на корректировку таких оценок :)

                          Посмотрите вот этот комментарий: habr.com/ru/post/517442/#comment_22022990
                          Человек, мудро описывает решение данной ситуации.
                            0
                            Зачастую, этих представлений нет в связи с ограниченностью времени архитектора, которое он тратит на корректировку таких оценок :)

                            Зависит от бюджета проекта и степени риска.
                            Для проектов с шестизначными суммами — это правило может и сработает. Для семизначных бюджетов и выше — время найдется. +- неделя на оценку точно будет, если это не тендерное предложение, если государственное или критическое для бизнеса — то там только требования будут месяца два… три собирать для подписания контракта и первичного бюджетирования.
                        0
                        del
                          +2
                          Все архитекторы смешались в кучу — энтерпрайз, систем, солюшн и т.д.
                          Но мое мнение — эта должность очень сильно себя дискредитировала. Особенно в крупных компаниях от 20 тысяч человек и более. Рисовальщики картинок и схемок, которые не хотят и не могут разбираться в системах, для которых предлагают решения, с известными только себе одним целями (вставить корпоративную систему аутентификации в мелкий проект через прослойку, которую не умеет ни одна, ни другая система — запросто).
                          Подсветить риски и помочь в выборе технологий продуктам? Держи карман шире.
                          И когда дело касается бюджетов с 7, 8, 9 нулями все становится только хуже и хуже.
                          Техлид — ок, архитектор — не ок.
                            0

                            Я бы еще добавил — коллега из американского банка в свое время рассказал, что там должность архитектора — это что-то вроде вахтера была (конкретно в его отделе, правда, пару лет назад).


                            Ну то есть основная задача была следующая: прийти, оценить проект; сходить к начальству и узнать свою точку зрения; вернуться в проект и озвучить сомнения.


                            Уже моё додумывание — если выдать должность "секретарь" или "ПМ", то не получится говорить "авторитетно", придется доказывать свою точку зрения, а здесь подобному человеку было бы сложно общаться с командой, которая уже несколько лет как в теме. А должность "архитектор" прекрасно подходит под данный сценарий.


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

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

                            Данный тезис можно продемонстрировать на примере задач, выполняемых мной в в качестве архитектора в проекте создания программного обеспечения для экономических подразделений крупной промышленной Компании. В проекте было задействовано помимо меня в разное время от 1 до 3 программистов и от 2 до 3 специалистов предметных областей. На начальном этапе количество пользователей составляло около 100 человек, в настоящее время количество активных пользователей превышает 1000 человек. Проект разрабатывался с 2009 по 2016 год.

                            Итак, функции архитектора специализированного программного обеспечения (далее ПО):
                            1. Разработка и развитие модели хранения данных и расчетной модели.
                            2. Настройка и расширение структуры данных ПО (объекты учета, типы и классы объектов учета, системные справочники).
                            3. Настройка компонентов подсистемы бизнес-транзакций ПО (бухгалтерские счета, проводки, документы, связи документов, фильтры счетов и проводок).
                            4. Расширение возможностей архитектуры действующей версии ПО и новой версии ПО 2.0 под новые задачи подразделений.
                            5. Организация перевода работы строительного подразделения Компании из замороженной версии ПО-Строительство на типовую модель данных ПО-Экономика, используемой экономическим подразделением Компании.
                            6. Постановка задач по развитию функциональности подсистемы бизнес-транзакций ПО и переносу форм устаревшей архитектуры на новую модель бизнес-транзакций.
                            7. Постановка задач перед внешними подрядчиками по разработке отдельных функций в новой версии ПО 2.0.
                            8. Адаптация настроек действующей версии ПО под требования программы переноса данных из действующей версии ПО в новую версию ПО 2.0.
                            9. Настройка автоматической прокачки данных документов на уровне базы данных MS SQL на языке Transact SQL и встроенного языка формул ПО с помощью подключаемого расчетного модуля в действующей версии ПО.
                            10. Создание и настройка форм пользовательских документов посредством конфигурационных файлов на Python-подобном упрощенном синтаксисе с последующей их компиляцией в конфигурационные файлы ПО в формате XML.
                            11. Создание колонок документов в базе данных и настройка формул для формульных колонок.
                            12. Помощь сотрудникам экономического подразделения Компании в настройке формул строк документов с особо сложной предметной логикой.
                            13. Поиск и исправление логических ошибок в расчетной системе ПО.
                            14. Предоставление прав доступа к ПО сотрудникам Компании.
                            15. Настройка расширенных прав доступа и предоставление в ним доступа сотрудникам предприятий Компании для решения специфических задач.
                            16. Консультирование подразделений Компании, применяющих ПО в своей работе, по эффективному применению ПО.
                            17. Контроль и координация деятельности сотрудников отдела информационного обеспечения в рамках текущего сопровождения ПО.
                            18. Контроль и координация деятельности всех сотрудников Компании, задействованных в процессе настройки и использования ПО, через трекер задач.
                            19. Разработка и проведение курсов подготовки пользователей ПО на площадке учебного центра Компании.
                            20. Арбитраж сложных организационных ситуаций, возникающих в процессе эксплуатации ПО между сотрудниками предприятий Компании, подразделений Компании и отдела информационного обеспечения.
                              +3
                              Вы меня искренне простите, но я не могу даже примерно определить Вашу роль в компании. В ваших функциях грубые нарушения областей компетенций. А также грубые нарушения корп. безопасности.

                              Приведу пример:
                              1. Разработка и развитие модели хранения данных и расчетной модели.

                              9. Настройка автоматической прокачки данных документов на уровне базы данных MS SQL на языке Transact SQL и встроенного языка формул ПО с помощью подключаемого расчетного модуля в действующей версии ПО.

                              vs
                              15. Настройка расширенных прав доступа и предоставление в ним доступа сотрудникам предприятий Компании для решения специфических задач.


                              Эти два пункта говорят о том, что Вы тот самый честный человек на ком стоит все предприятие. Вы сами и пилити системы и эксплуатируете, да еще и доступы предоставляете. Если завтра вы станете немного менее честным и более хитрым… или что более вероятно — на ваше место придет такой человек, то предприятие может в одночасье исчезнуть или сильно пострадать.

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

                              Остается лишь надеяться, что Вам это нравится.
                                +1
                                Согласен, что многие вещи действительно «далеки от хороших практик». Тем не менее, это был проект, в основном завершенный в 2016 году, после чего многие организационные вещи были приведены в классический вид, в том числе вопросы предоставления прав доступа. Кроме того, многие технические и организационные проблемы, напрямую не связанные с проектом, были оптимизированы под его влиянием.

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

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

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

                              в крупных компаниях много бумагомарания, большие бюджеты выделяются только пройдя через бесчисленные комитеты и митинги, и для таких целей подойдет Архитектор.
                              Человек который создает L0/L1 диаграмму всего проекта — набросок архитектурного решения и поддерживает ее в актуальности. Большой софт обычнл имеет кучу взаимосвязей и интеграций, и индивидуальные вещи могут аутсорситься на галеры, и Архитектор помогает разбить предметную область на домены и очертить границы — гдя чья ответственность, а также как будет вырисовываться интеграция.


                              простой пример: Компании нужен интранет-сайт для сотрудников для планирования отпусков. Разработчик-формошлеп модет сказать: да щас я забацаю это на реакте за неделю.
                              А архитектор скажет, так тут нужен модуль SSPI авторизация через AD, чтобы не спрашивать пароль, также standby база и сервак нужны в другом датацентре как hot standby на слуяай disaster recovery, согласно стандартам компании, а данные по отпускам нужно подсасывать из системы учета кадров/data warehouse, а вот функции аппрувала отпусков нужно делегировать двум вышестоящим менеджерам, на члуяай если один из них в отпуске и т.д и т.п


                              со временем эта идея "давайте забайаем сайт с двумя формами" превращается в типичное ентерпрайзное решение благодаря архитекторам (гуглите FizzBuzz Enterprise Edition для примера)

                                0
                                А архитектор скажет, так тут нужен модуль SSPI авторизация через AD, чтобы не спрашивать пароль, также standby база и сервак нужны в другом датацентре как hot standby на слуяай disaster recovery, согласно стандартам компании, а данные по отпускам нужно подсасывать из системы учета кадров/data warehouse, а вот функции аппрувала отпусков нужно делегировать двум вышестоящим менеджерам, на члуяай если один из них в отпуске и т.д и т.п

                                +100, так и скажет. Но он еще скажет почему.
                                +1
                                В первую очередь архитектор, и в том числе программный архитектор должен обладать прокачанным системным мышлением. Не просто «системным мышлением» а научными знаниями, усвоенными и переваренными, которые накоплены в научной дисциплине — «системное проектирование», как более узкоспециализированной областью системного мышления.
                                Могу порекомендовать отличный курс от Анатолия Левенчука на курьсере от МФТИ www.coursera.org/learn/system-thinking, не сочтите за рекламу, но я просто не понимаю, как можно что-либо проектировать, не обладая этим базовым минимумом.
                                  0
                                  Не холивара ради. Попробую объяснить.
                                  Нау́ка — область человеческой деятельности, направленная на выработку и систематизацию объективных знаний о действительности

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

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

                                  В итоге, к сожалению, приходя на работу студент вынужден полностью переучиваться.

                                  Повторюсь, с очень большой вероятностью ему читали толковый курс. Но он запомнил из него не то, что нужно было. И не смог построить правильные связи. Не научился использовать.

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

                                  Поэтому, еще в институте студенты делятся на две категории: теоретики и практики. Теоретики в среднем учатся хорошо по всем предметам. А практики автоматом получают оценки по конкретным предметам и имеют раскошные хвосты по другим. Просто потому, что они не видят ценности в этих предметах.
                                    0
                                    спасибо за ссылку. как раз та такие комменты и люблю хабр
                                    0
                                    Ох, смешались в кучу… Если мы возьмем тот же тогаф за глоссарий, то видимо мы говорим про applicatons с примесью technology. Неплохо было бы рассказать, хотя бы вскользь, что есть и другие роли, и хотя бы верхнеуровневые отличия. Еще момент, который наверное бы стоило отметить что границы эти довольно зыбкие и роль applications может выполнять аналитик, а technology — qa. Да, и совсем не зашел посыл про «должен-не должен». Архитектор — это человек который имеет богатый опыт ошибок, а также желание на основе опыта и навыков принимать вместе с командой более осмысленные решения в процессе реализации идей. Без желания ничего не сработает на мой взгляд.

                                    Only users with full accounts can post comments. Log in, please.