Правильная архитектура данных с первых спринтов +3


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

Иногда размер технического долга оказывается настолько большим, что для его устранения запускаются отдельные проекты, рассчитанные на месяцы и годы - а это сопоставимо с 5-10 time-to-market новых решений. Соответственно, все новые запуски откладываются до тех пор, пока авгиевы конюшни не будут расчищены, покрашены и перестроены. Отдельное зрелище - СТО, который убеждает СЕО и добрую половину правления, а также акционеров, потратить несколько тысяч человекочасов драгоценных разработчиков на то, что по завершении не поможет бизнесу моментально, а только ускорит на неизвестное время получение выгод от новых продуктов в будущем. Правда, после того, как запуск каждого из этих продуктов будет отложен на несколько месяцев.

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

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

  1. Проблема 1. Ваша архитектура построена на микросервисах, обменивающихся данными. Одни и те же данные могут храниться в нескольких местах, но ни одно из этих мест не назначено “местом правды” (”the single source of truth”). В результате работы различных процессов в компании, данные в разных местах меняются, не синхронизируются, и потому начинают противоречить друг другу. Без иерархии источников данных не понятно, какие данные - самые актуальные. Яркий пример - мета данные о контрагентах (адрес, ЛПР, реквизиты, ИНН, номер банковского счета и т.д.), которые меняются не очень часто, но используются в нескольких местах: в бухгалтерии, в операциях, в продажах. Контакты контрагента поменялись по разу в каждом месте - и вот уже не ясно, каким образом теперь реально можно связаться с контрагентом, чтобы, например, что-то ему допродать.

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

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

Ситуация:

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

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

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

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

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

Решение:

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

  2. Определите круг людей, которые будут использовать создаваемые решения, либо хорошо представляют потенциальные потребности клиентов, и какие из них более вероятно окажутся важными (например, “у конкурентов есть фича Х, это норма рынка и ей активно пользуются клиенты. Пока у нас нет идей по-лучше, нам придется сделать Х и у себя, иначе мы не убедим выбрать нас, а не конкурентов.”). Это могут быть сотрудники продаж, маркетинга, операций, бухгалтерии, аналитики и т.д.

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

  4. Проведите цикл бесед с представителями каждой функции из пункта 2, стараясь ответить на следующие вопросы

    1. Какие процессы / действия / работу в целом нам вероятно предстоит делать на стороне этой функции, чтобы работать с / поддерживать продукты АВС, которые мы сейчас держим в уме?

    2. Какие данные будут необходимы для этих процессов / действий / работы?

    3. Насколько детальными они должны быть?

    4. Как часто эти данные должны обновляться? Каждую секунду / минуту / час / день / месяц?

    5. Как часто нужно будет обращаться к этим данным в ходе работы? То есть насколько большую нагрузку нужно иметь ввиду?

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

    1. Из каких модулей должна состоять будущая архитектура?

    2. Какие данные должны быть доступны каждому модулю?

    3. Где эти данные должны храниться и, что особенно важно, какое место должно быть “местом правды”, то есть содержащим самую корректную и актуальную информацию?

    4. Как могут быть связаны модули (например, посредством API?)? То есть какой информацией и по каким маршрутам они должны обмениваться?

  6. Отрисованная на предыдущем шаге архитектура - это первый черновик. Прежде чем на нее ориентироваться, необходимо проверить ее с “заказчиками”. Для этого нужно показать архитектуру, и проговорить ее. Например, в таком формате:

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

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

    3. Вопросы к заказчикам:

      1. Все ли вам кажется разумным и подходящим вам?

      2. Есть ли новые требования, которые нам стоит учесть дополнительно? Например, не вспомнили о них в первый раз, либо между шагами 4 и 6 узнали что-то новое? Если такие есть, то нужно точечно повторить шаги 5 и 6.

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

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

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

    3. По мере того, как команда проекта будет получать опыт, ее представления о рынке, его потребностях, а потому - о будущих продуктах, будут меняться. Это будет означать, что и целевая архитектура будет меняться. Поэтому раз в несколько недель или месяцев следует повторять шаги 3-6, и таким образом поддерживать актуальность целевой картинки. СРО или менеджер продукта видится мне разумным лидером такого процесса. Хорошая новость - вторая и последующие итерации шагов 3-6 будут требовать кратно меньше усилий. Возможно, будет достаточно дня или нескольких часов.




Комментарии (8):

  1. ap1973
    /#24343206 / +4

    Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer.

    ©Гради Буч

  2. XaBoK
    /#24343806

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

    Эта идея и приводит вас в тот дивный мир legacy, о котором вы так нелестно отзывались в начале. Вы уже со старта стоите легаси. Архитектура - это основа. Она необходима, для экономии усилий и времени. Замена основы - дорого и долго а значит и лишает всякого смысла изначальное планирование. Хотите заняться прототипированием - пишите говнокод, обгоняйте конкурентов, а уже потом стройте архитектуру и продукт.

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

    • smple
      /#24344102

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

      Если бы все придерживались этому правилу как бы появились "архитекторы" ?

      • XaBoK
        /#24344620

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

        • smple
          /#24345012

          Возможно вы ответили не на ту ветку ?

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

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

          ps минус поставил вам не я.

          • XaBoK
            /#24345190

            Нет, веткой я не ошибся и минус мне видимо за не ясное изложение ответа заслуженно.

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

            Моя аналогия с разработчиком подчёркивает важность того, что сначала есть человек, а потом результат. Не появляется код, а потом думают может нам разработчика нанять... Кстати, вот с девопсами часто работает как раз наоборот - сначала проблема, а потом девопс как решение.

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

            Архитектура проекта - это долгий процесс и мой опыт о том как его уложить в динамику и agile тут.

            • smple
              /#24346066

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

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

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

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

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

              Не понимание сложности и смыла процесса приводит к тому, что каждый вставляет свои 5 копеек, а ответственности никто не несет

              Этому даже дали название DDD, когда нам было сложно понимать процессы либо они слишком сложны, поэтому будем применять универсальные решения и код тут далеко не на первом месте.

              а ответственности никто не несет.

              А кто должен нести ответственность ? а за что ответственность ? за "архитектуру" или за продукт или за его реализацию ? кто может проверить "архитектуру" кроме "Васи"?

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

              Что в этом плохого ?

              если например реализовали процесс покупки товара через корзину, а потом бизнес сказал ой, нам надо не продавать товар, а осуществлять подписку на ... и следом за изменением процесса изменили "архитектуру" и решение (корзины) и текущая система позволила это сделать без side effect для системы в целом, это ли не пример хорошей архитектуры ?

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

              Архитектура проекта - это долгий процесс и мой опыт о том как его уложить в динамику и agile тут.

              Не читал, добавил в закладки прочитаю позже.

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

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

    • DrinkFromTheCup
      /#24344264 / +2

      Архитектуру можно сравнительно точно определить по процессу выше, чётко осознав и сформулировав:

      • что ДОЛЖНО делать новое решение (каков конкретный круг задач - хранить и раздавать данные контрагентов, предположительно, юрлиц например, как в статье)

      • что НЕ ДОЛЖНО делать новое решение (что из смежных областей и схожих задач точно не понадобится - например, относительно примера из статьи, должны ли мы будем хранить данные физлиц, можем ли мы в будущем заниматься физлицами. Если не можем - то и заранее планировать циркуляцию специфических для физлиц данных не нужно)

      В т. ч. именно за этим нужны пункты 2-4.

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

      Либо присмотреться к участникам процесса повнимательнее...

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

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