Энтерпрайз

Мы сдвинулись еще на шаг с прошлой точки. Раз уж мы тут все люди опытные, то очевидно, что мы попали в список финалистов тендера. БигБиз любит выход на бис! Поэтому финалистов будут смотреть еще раз и с пристрастием. Мы же с вами говорим о таком махровом энтерпайзе - в белом плаще с кровавым подбоем. А значит и стоимость проекта будет как внешний долг Либерии. При таких раскладах лучше пере-, чем недо-. Так что, в зависимости от клиента и количества Либерий стандартом будет либо крещением боем, либо внешний аудит.

Дуэль!

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

Для начала вас поздравят с тем, что вы один из анонимных йкодзун (количество и имена держатся в секрете), которые сойдутся в бесконтактной схватке (секрет должен оставаться секретом) в произвольном порядке (секрет же). Обычно есть чётко оговорённые сроки и условия схватки. Обычно это одно место, в котором один за одним, вендоры демонстрируют свою систему и отдают её на пробу тем, кто является целевой аудиторией потенциальные пользователи. Почему локация одна, а не несколько параллельно? А по тому, что комитет там всё-таки будет присутствовать и мотаться по разным местам им обычно не хочется. Классическим местом будет уже существующая тестовая локация, где обкатывают новые стратегии и маркетинговые фишки. Что-то небольшое возле центрального офиса или внутри него там, где 90% клиентов будут работники самого клиента. Либо это будет какая-нибудь зона отчуждения. Один клиент в час, минимальная публичность, никакой связи с реальностью. Добро пожаловать в Зону, сталкер!

Зона хороша своими аномалиями. Люди там хорошие - простые. Они не так ровно ходят по корпоративной прямой и не любят лишний шум. Если ваша компания не первая на тестовой площадке, то вы без труда найдёте кучу информации о ваших конкурентах и зачастую даже получите отзыв. Однако и инфраструктура там не комильфо. Поэтому лучшей стратегией будет поселить рядом своего человека. Не обязательно ведущего разработчика, но обязательно сведущего. Я - добровольцем, но не всегда разрешают (бюджет). Почему еду? Не стоит недооценивать значение Ничегонеделания. Не всегда служба поддержки и разработчик умеют сгладить углы неизбежных ЧП, а самое главное наблюдать и анализировать. Можно попросить не общаться с клиентом, но нельзя быстро научить делать это правильно и с пользой. Мнение людей, которые привыкли к какой-то определенной системе и последовательности действий, очень редко будет положительным, если каждую неделю менять им всё привычное. Я стараюсь не лезть к ним с расспросами, да и зачастую, вам не дадут свободного доступа на полигон. Хотя именно в таких местах, люди любят личное общение и не будут звонить в службу поддержки, а тупо забьют и будут работать в обход системы (худший для нас сценарий). Если нельзя проникнуть внутрь, то обычно можно понаблюдать со стороны. Как часто тупит персонал перед экраном? Насколько быстрее они тыкают кнопки на следующий день? Что они делают не так как вы ожидали аномалии рабочих процессов и срезание пути - здесь будут обычным делом. Это тот самый важный фактор (BAU), который никогда не укажут в задании великие стратеги клиента, потому что никогда не щупали земли, которую видят на штабных картах. Только побывав в зоне, вы узнаете куда кинут ваш сервер и сколько сигарет будет лежать на клавиатуре. Это даст вам возможность прикинуть живучесть железа, стабильность связи, необходимость альтернативных средств ввода, а иногда даже желательность перевода. Да, жители Олимпа могут забыть, что есть в их землях и диалекты и иностранные рабочие. Вам же это важно, так как при первых попытках внедрения, именно отзывы и количество ошибок, которые будут делать пользователи будут решать успешность проекта и скорость развёртки решения. Если дворец падает, то виноват всегда архитектор. Правда, если дворец превзойдёт ожидания

Немного о связи.

В варианте под боком картина другая. Тут персонал привык к тому, что всё тлен. Каждую неделю к ним приходят с очередной гениальной идеей из штаба и перестраивают устав, не успевший стать привычным. У них не будет отрицательных эмоций, но и положительных тоже. Они давно на всё положили и просто улыбаются в камеру. Это центр крупного города и отдохнуть здесь можно хорошо, а вот работать нет. Начальство будет крутиться всегда рядом. Ваше присутствие будет фиксироваться и восприниматься как неуверенность в своём продукте или сервисе поддержки. Вот в этом варианте вместо личного общения предпочтут звонки и письма. Службу поддержки будут напрягать как нестыковками, так и непонятками. Сценарии тут будут обыгрывать и это больше будет похоже на обычный приёмный тест. Зато инфраструктура тут на высшем уровне. Шанс спровоцировать DR почти нулевой. То есть этот вариант теста лучше всего просчитывается. Не подготовится основательно к заранее известным сценариям один из смертных грехов. Выяснить, кто и что здесь был или будет, почти не реально, так же, как и понять, насколько адекватно ведут себя пользователи и сама система. А потому, постарайтесь иметь какой-то канал телеметрии и информативный поток логов. Может технически у вас всё это есть, но не забывайте, что большой клиент - всегда прав, и надо будет убеждать его в необходимости работы этого модуля. Лучше всего, если вы представите его жизненно необходимым и не отключаемым. Вроде как мы может менять уровень логирования, но не можем отключить. Требование для аудита безопасности идеальная уловка. Данные потом можно проанализировать и представить клиенту, если вы там в шоколаде средняя скорость процесса, количество операций, утилизация ресурсов. Не важно, как с этим у конкурентов, если они не позаботились предоставить такой же доклад. Это делает вас особенным (+1 к харизме).

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

Всевидящий глаз.

Если дуэль не состоялась, то к вам посылают дилижанс аудиторов. Это третья сторона независимые эксперты из не менее крупной корпорации. Комиссия из 3-4 человек с разными специми на подхвате. Основной костяк будет стандартным: менеджер, чья подпись будет стоять на всех документах; секретарь-стенографист; технический специалист из близкой вам отрасли. К ним по вызову будут присоединяться специалисты безопасности, инженеры инфраструктуры, фронт и бекэнд эксперты. Стоит весь этот цирк не дешево, так что случается не часто. При очень крупных проектах, потенциальном партнерстве или перед полным выкупом компании или прав на проект. Уровень компетенции этих ребят разный. Возможно, никто из них не сможет создать нечто подобное тому, что они оценивают. Зато они видели уже сотни таких систем и могут легко сравнивать решения, которые уже рассматривали, с вашим. И самое главное они умеют преподать результат своей работы клиенту. Так что, когда на первый мой аудит приехали 3 грации с суммарным опытом работы равному моему, я был слегка расстроен. Компания, конечно, приятная, но опять перестраиваться в режим продаж, на отведенные под аудит 3 недели, совсем не хотелось. Однако. Девушки с лёгкостью призывали нужные силы по скайпу и в конце каждой недели выдавали подробный и, главное, красивый документ, описывающий процессы и технологии, намного лучше того, что мы им демонстрировали. Признаюсь честно, часть их докладов в своих презентациях я использую до сих пор. Тогда я понял, насколько важен дизайнер.

Самое главное, что вам нужно помнить аудитор не только не враг, а даже друг. Эти компании рассчитывают на длительное партнерство с клиентом и хотят вести аудит и консультации вашего проекта в течение всего срока разработки и эксплуатации. И если в финале тендера есть 2 компании, то аудиторам будет выгодно если выиграют обе и разделят сферы влияния по типу операции или географии. Кроме того, чтоб сохранить такую возможность, аудитор не только укажет вам на ваши сильные и слабые стороны, но и даст совет как лучше всё поправить. Этим стоит воспользоваться. Свежий взгляд со стороны это то, чего частно не хватает в крупных компаниях. Доброе имя для консалтинговой компании значит очень много. Поэтому они не расскажут вам о конкурентах (и даже могут оказаться от кофе в офисе, если им покажется, что это нечто особенное политики конфликта интересов и взяток выжигаются у них на сетчатке). Зато с удовольствием поведают о трендах в индустрии, о провалах и новинках, различиях подхода по странам и менталитетам. Так что, если вы на данном этапе не продумали все мелочи, то вас на них ловить не будут. Тут у вас отличная возможность посоветоваться. Я, по неопытности, пытался на ходу продумывать детали и тут же из оформлять в диаграммы, раскидывая потенциальные сценарии и мысленно считая за и против. Стоило прямо сказать, что детали продумаем позже, перед непосредственной разработкой, а на данном этапе есть вот такая задумка. Результат был бы тот же, а нервов бы сэкономил кучу. Тоже самое с аудитом безопасности и эксплуатационной стратегии. Так как секьюрити эксперты были на последней неделе и делали проверку с открытым кодом, то мы выдали им полный список известных нам дыр и показали распланированный бэклог с эпиками на эти дыры. Аудиторы погоняли свои тесты, посмотрели уже закрытые эпики и их реализацию в коде. Удостоверились в том, что по плану всё необходимое будет закрыто до даты выхода проекта в свет, и дали высокий бал. Главное показать, что то, что уже есть высокого качества. И то, что вы знаете, чего у вас не хватает и когда это будет.

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

В остатке

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

---

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

• Полевые испытания

  • Вариант у черта на куличках. Настоящая жизнь и настоящие люди.

  • Вариант рукой подать. Всё строго по рецептуре, подавать охлажденным.

• Due Diligence
  Созидатели и наблюдатели. Не надо пускать пыль в глаза и постарайтесь прислушиваться к дельным рекомендациям. Не бойтесь просить совета. Не пытайтесь купить или задобрить.

Да, если запустить, то будет больно. Ну а пока, возрадуемся же выигранному конкурсу! Ожидать горы золота или похвалы будет как минимум глупо. Солнце ещё высоко и время работать. Дядюшка Скрудж не выстроил бы своей империи, если б сразу бил по рукам и переходил к оплате. Поэтому его воплощение в вашем энтерпрайз-заказчике в очередной раз просто улыбнётся и опять поправит очки. Это, внучка, чтобы получше тебя видеть. И, конечно, чтоб читать текст приложений к контракту мелким шрифтом. Техническая часть всегда запрятана где-нибудь в Appendix 7/C.1.1

Copy of a written deal by Christoph Haizmann from 1669.

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

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

Пятиминутка ненависти и личного опыта

Функциональные требования

Начнём с очевидного, но невероятного. Помните на первых этапах подачу иконостаса с тех. стеком? Так вот время его перепроверить на соответствие всем изложенным в задании сценариям. И самое главное - передать ответственным игрокам с вашей стороны список жёстких конструкций. Таких жёстких, что легко ломают не только мозг при осмотре, но и спину при падении. У каждой технологии есть ограничения. Эти границы могут сильно влиять на бизнес. Для отдела продуктового дизайна и для вашего клиента подобные вещи совсем не очевидны. Даже если для вас это настолько тривиально, что и упоминания не стоит. Самым популярным кейсом будет не требование работы в оффлайн с полностью облачным бекэндом. Это на втором месте. На первом конечно же полная согласованность всех данных с постоянной доступностью в распределенной системе. На этом невысказанном предположении зачастую строится очень много критического функционала. Сколько бы раз вы не повторяли мантру Брюера все будут считать это какой-то теоретической лабудой. Мы то не в каменном веке, вот сейчас как сделаем Даже эксперты, которых вам предлагают облачные платформы в 80% (5 из 6 на моём опыте) уверены, что если вы работаете по well-architectured шаблонам, то никаких проблем с согласованностью данных не будет. Это проблемы конкурентов. В нашем облаке такого быть не может!.

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

Дедлайны при этом никто не двигает. Ко времени крупных конфликтов требований обе стороны уже где-нибудь накосячили и предпочитают не трогать status quo. Несмотря на то, что я упомянул выход в свет через год, релиз первой версии обычно намного раньше. Просто в начале он попадает на синтетические тесты в лаборатории (UAT, SIT, PPT). Там же первые интеграционные проблемы, не готовность инфраструктур клиента, баги у всех участников процесса и ещё куча приятных мелочей. Так что первые полгода всё копаются в сете известных требований, пытаясь наладить процессы и стабилизировать системы. На этом этапе сюрпризов практически не возникает. Сюрпризом будет, если всё заработает с первого раза.

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

Нефункциональные требования

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

Appendix Header

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

И всё в таком духе. Абстрактный сценарий и какой-то лимит времени. Тот, кто эти цифры даёт ваш заказчик. Ему не нужно с этим разбираться. Он просто озвучивает желания. Желания всегда ведут к результату лестницей Пенроуза. Так что в начале нужно разобрать всё, ступенькой за ступенькой, и сложить всё в поленницу. А потом упорядочить и структурировать. Что значит структурирование? Построить цепочку зависимостей сценариев в последовательности исполнения. Рассмотрим наш теоретический пример. Сразу скажу, что работать лучше на листе или доске, так как в красивые деревья не вырастут. Будет сложная диаграмма или зацикленные графы. Я вот подобрал удобные сценарии, но всё равно нарисовать в ворде получается, как-то не очень:

Scenario Tree

С подобной диаграммой работать легче, а самое главное намного проще объяснить другим. Надо сразу вписывать недостающие шаги. Допустим процесс логина в таблице отсутствует, но его составляющие есть. Опять-таки, если вокруг вас все специалисты и у вас такой авторитет, что решения объяснять не надо, то можно и пропустить живопись. Вполне ведь себе реальная ситуация, что технический специалист со стороны исполнителя просто говорит: тут вот будет 5 вместо 2 - и заказчик сразу соглашается. Тем же, кто работает в реальном мире, советую рисовать. А потом быстро подбивать время и анализировать:

• Минута выделена на загрузку какой-то страницы журнала. А эта страница у нас в облаке. И вот первое противоречие. Серверу разрешено 2 минуты, а клиенту 1 минута. Значит у нас 2 варианта вписать, что загрузка журнала будет без данных (только клиент и кэш), либо указать на зависимость того, что журнал не может загрузиться быстрее ответа сервера.

• Авторизация и аутентификация по минуте. Значит логин в облако займет 2 минуты, только если оба действия будут в одном запросе. И да, если вам понятно, что 1+1 = 2 только в презентации, а на самом деле есть еще прослойки верификаций, сериализации и тому подобное, то контракту это безразлично. Поэтому либо явным образом указывайте логин в таблице со всеми поправками, либо мелкий текст агрегация функций будет вносить дополнительную задержку в процесс.

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

Downtime breakdown

Когда вы разложили все тайминги и внесли коррективы, то теперь вспоминаем эскиз архитектуры и проверяем его. Вот тут указанно 5 лет данных хранить база подходит? Как повлияет такой объём данных на производительность? Что синхронизируется на клиента и при каком соединении клиента и канале сервера влезает в 5 минут? То есть в прошлом шаге мы как бы смотрели вертикально, а теперь проходим горизонтально, рассматривая сценарий, а не ветку. То, что указали в таблице требований, заказчику видится как критичная функциональность. Зачастую, это те участки, которые плохо работают у него сейчас болевые точки. Часто повторяющиеся пункты в диаграмме потенциальные места для масштабирования.

На каждую строку в таблице нужно расписать точный сценарий с минимальным шумом. Лучше всего оторванный от жизни (лабораторный) и с учётом погрешностей. Задача дать настолько подробное описание, чтоб две разные команды на разных тестовых стендах смогли повторить и получить одинаковые данные. Retestability. Берём логин как пример:

Сервис Login выполненный на системе в сети (указываете состояние и скорость сети до сервера), клиентское приложение на машине с рекомендованными параметрами или выше (расписываете железо, включая скорость дисков), с системой включающей только минимально необходимое (лист prerequisites) в оптимальной конфигурации (ссылка на ваши документы) и горячем состоянии (после рестарта станции сделано 3 логина и тестируется только 4-ый успешный, и не позже чем через 5 секунда с последнего), без взаимодействия со внешними системами (всякие sso, oauth провайдеры, active directory и тд), с уровнем логирования (какой-то минимум) в 11 утра во вторник (это важно, если у вас сервер в облаке у инфраструктуры есть нагрузка и без вас) без особых событий (чемпионаты, чёрные пятницы и эпидемии), при ручном замере от нажатия клавиши ввод (триггер начала процесса старт таймера), до появления приветственной надписи такая то (конечная точка стоп таймера) в процессе без ошибок (может случиться какой-нибудь переезд/перенаправление сервисов) займёт не больше 2 секунд в 99% случаев (нужен временной промежуток, допустим месяц) с поправкой 280 мс х 2 на человеческую реакцию. Скрипт для приведения баз данных в эталонное состояние прилагается (ведь важно сколько юзеров и какая сложность ролей и размер базы). Почему это важно я уже упоминал в прошлых статьях, но приведу еще пару примеров ниже.

Из опыта:

Требования между строк

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

Загвоздка безопасности в том, что тут, зачастую, не может быть обратной совместимости. Подозрительные люди говорят вам, что у них есть копия ключа от вашего офиса. Вы же не вставите новый замок в соседнюю дверь, оставив в основной старый. Даже если будет куча тех, кому вы не смогли сразу выдать новый ключ. Так и тут. Если сломали щиты, то либо в проде появляются сразу две системы: новая и старая, и постепенно идёт миграция пользователей из уязвимой в защищенную версию. Либо мы всё ломаем и есть только новая версия и те, кого мы не обслуживаем до обновления. И тут вы опять упрётесь рогами в те же ворота SLA о доступности системы.

Эхо из прошлого.

Кстати, о доступности. Вы ведь понимаете, что доступность для пользователя системы с облачным сервисом будет равна устойчивости машины, соединения, электроснабжения и только потом эти хвалёные 99.99999. Заказчика мало волнует то, что где-то в облаке всё работает, если конкретный человек в конкретном офисе не сможет этим воспользоваться. Так что объясните это хорошо своим коллегам (на пальцах, как у якудза), которые будут подписывать. Самые простые для понимания примеры в комбинаторике монетки и кубики: У нас есть несколько кубиков, каждый на 365 граней и представляют собой доступность или надежность инфраструктуры в годовом масштабе. Подставляем данные, я люблю использовать полу-реальные данные со своего лаптопа на примере доступа к электронной почте некий облачный жи-mail. Открываете логи раутера, журнал оси и показываете пару записей о перезагрузке или разрыве соединения, а потом экстраполируете на месяц и год. Допустим за последний год у нас не было электричества 17 часов, лаптоп был в ремонте 30 часов, проблемы с соединением 4 минуты в сутки, а это 24 часа в год. И последний кубик недоступность самого облака, которая будет не больше часа в год. Так как любая из этих проблем означает отсутствие доступа к мейлам, то шанс проверить жи-почту в прошлом году был:

availability-probability

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

Ещё разок вернёмся к пункту 10 в таблице требований. Что конкретно он означает: интервал синхронизации или временной лимит работы в оффлайн? Двусмысленность в контракте лучше не допускать. Если вам повезло, и компания аудитор выступает арбитром во время всего периода развёртывания, то это уменьшит риск разночтений. Аудиторы страшный враг вашей компании и ваш хороший друг. Они будут мешать эффективным менеджерам игнорировать заявленные процедуры и не применять продемонстрированные процессы, но зато смогут помочь объяснить клиенту сложность некоторых требований и прийти к компромиссам.

---

Продолжение. К предыдущим постам и карте цикла.

Да, если аппендикс запустить, то будет больно. Ну а пока, возрадуемся же выигранному конкурсу! Ожидать горы золота или похвалы будет как минимум глупо. Солнце ещё высоко и время работать. Дядюшка Скрудж не выстроил бы своей империи, если б сразу бил по рукам и переходил к оплате. Поэтому его воплощение в вашем энтерпрайз-заказчике в очередной раз просто улыбнётся и опять поправит очки. Это, внучка, чтобы получше тебя видеть. И, конечно, чтоб читать текст приложений к контракту мелким шрифтом. Техническая часть всегда запрятана где-нибудь в Appendix 7/C.1.1

Copy of a written deal by Christoph Haizmann from 1669.

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

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

Пятиминутка ненависти и личного опыта

Функциональные требования

Начнём с очевидного, но невероятного. Помните на первых этапах подачу иконостаса с тех. стеком? Так вот время его перепроверить на соответствие всем изложенным в задании сценариям. И самое главное - передать ответственным игрокам с вашей стороны список жёстких конструкций. Таких жёстких, что легко ломают не только мозг при осмотре, но и спину при падении. У каждой технологии есть ограничения. Эти границы могут сильно влиять на бизнес. Для отдела продуктового дизайна и для вашего клиента подобные вещи совсем не очевидны. Даже если для вас это настолько тривиально, что и упоминания не стоит. Самым популярным кейсом будет не требование работы в оффлайн с полностью облачным бекэндом. Это на втором месте. На первом конечно же полная согласованность всех данных с постоянной доступностью в распределенной системе. На этом невысказанном предположении зачастую строится очень много критического функционала. Сколько бы раз вы не повторяли мантру Брюера все будут считать это какой-то теоретической лабудой. Мы то не в каменном веке, вот сейчас как сделаем Даже эксперты, которых вам предлагают облачные платформы в 80% (5 из 6 на моём опыте) уверены, что если вы работаете по well-architectured шаблонам, то никаких проблем с согласованностью данных не будет. Это проблемы конкурентов. В нашем облаке такого быть не может!.

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

Дедлайны при этом никто не двигает. Ко времени крупных конфликтов требований обе стороны уже где-нибудь накосячили и предпочитают не трогать status quo. Несмотря на то, что я упомянул выход в свет через год, релиз первой версии обычно намного раньше. Просто в начале он попадает на синтетические тесты в лаборатории (UAT, SIT, PPT). Там же первые интеграционные проблемы, не готовность инфраструктур клиента, баги у всех участников процесса и ещё куча приятных мелочей. Так что первые полгода всё копаются в сете известных требований, пытаясь наладить процессы и стабилизировать системы. На этом этапе сюрпризов практически не возникает. Сюрпризом будет, если всё заработает с первого раза.

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

Нефункциональные требования

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

Appendix Header

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

И всё в таком духе. Абстрактный сценарий и какой-то лимит времени. Тот, кто эти цифры даёт ваш заказчик. Ему не нужно с этим разбираться. Он просто озвучивает желания. Желания всегда ведут к результату лестницей Пенроуза. Так что в начале нужно разобрать всё, ступенькой за ступенькой, и сложить всё в поленницу. А потом упорядочить и структурировать. Что значит структурирование? Построить цепочку зависимостей сценариев в последовательности исполнения. Рассмотрим наш теоретический пример. Сразу скажу, что работать лучше на листе или доске, так как в красивые деревья не вырастут. Будет сложная диаграмма или зацикленные графы. Я вот подобрал удобные сценарии, но всё равно нарисовать в ворде получается, как-то не очень:

Scenario Tree

С подобной диаграммой работать легче, а самое главное намного проще объяснить другим. Надо сразу вписывать недостающие шаги. Допустим процесс логина в таблице отсутствует, но его составляющие есть. Опять-таки, если вокруг вас все специалисты и у вас такой авторитет, что решения объяснять не надо, то можно и пропустить живопись. Вполне ведь себе реальная ситуация, что технический специалист со стороны исполнителя просто говорит: тут вот будет 5 вместо 2 - и заказчик сразу соглашается. Тем же, кто работает в реальном мире, советую рисовать. А потом быстро подбивать время и анализировать:

• Минута выделена на загрузку какой-то страницы журнала. А эта страница у нас в облаке. И вот первое противоречие. Серверу разрешено 2 минуты, а клиенту 1 минута. Значит у нас 2 варианта вписать, что загрузка журнала будет без данных (только клиент и кэш), либо указать на зависимость того, что журнал не может загрузиться быстрее ответа сервера.

• Авторизация и аутентификация по минуте. Значит логин в облако займет 2 минуты, только если оба действия будут в одном запросе. И да, если вам понятно, что 1+1 = 2 только в презентации, а на самом деле есть еще прослойки верификаций, сериализации и тому подобное, то контракту это безразлично. Поэтому либо явным образом указывайте логин в таблице со всеми поправками, либо мелкий текст агрегация функций будет вносить дополнительную задержку в процесс.

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

Downtime breakdown

Когда вы разложили все тайминги и внесли коррективы, то теперь вспоминаем эскиз архитектуры и проверяем его. Вот тут указанно 5 лет данных хранить база подходит? Как повлияет такой объём данных на производительность? Что синхронизируется на клиента и при каком соединении клиента и канале сервера влезает в 5 минут? То есть в прошлом шаге мы как бы смотрели вертикально, а теперь проходим горизонтально, рассматривая сценарий, а не ветку. То, что указали в таблице требований, заказчику видится как критичная функциональность. Зачастую, это те участки, которые плохо работают у него сейчас болевые точки. Часто повторяющиеся пункты в диаграмме потенциальные места для масштабирования.

На каждую строку в таблице нужно расписать точный сценарий с минимальным шумом. Лучше всего оторванный от жизни (лабораторный) и с учётом погрешностей. Задача дать настолько подробное описание, чтоб две разные команды на разных тестовых стендах смогли повторить и получить одинаковые данные. Retestability. Берём логин как пример:

Сервис Login выполненный на системе в сети (указываете состояние и скорость сети до сервера), клиентское приложение на машине с рекомендованными параметрами или выше (расписываете железо, включая скорость дисков), с системой включающей только минимально необходимое (лист prerequisites) в оптимальной конфигурации (ссылка на ваши документы) и горячем состоянии (после рестарта станции сделано 3 логина и тестируется только 4-ый успешный, и не позже чем через 5 секунда с последнего), без взаимодействия со внешними системами (всякие sso, oauth провайдеры, active directory и тд), с уровнем логирования (какой-то минимум) в 11 утра во вторник (это важно, если у вас сервер в облаке у инфраструктуры есть нагрузка и без вас) без особых событий (чемпионаты, чёрные пятницы и эпидемии), при ручном замере от нажатия клавиши ввод (триггер начала процесса старт таймера), до появления приветственной надписи такая то (конечная точка стоп таймера) в процессе без ошибок (может случиться какой-нибудь переезд/перенаправление сервисов) займёт не больше 2 секунд в 99% случаев (нужен временной промежуток, допустим месяц) с поправкой 280 мс х 2 на человеческую реакцию. Скрипт для приведения баз данных в эталонное состояние прилагается (ведь важно сколько юзеров и какая сложность ролей и размер базы). Почему это важно я уже упоминал в прошлых статьях, но приведу еще пару примеров ниже.

Из опыта:

Требования между строк

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

Загвоздка безопасности в том, что тут, зачастую, не может быть обратной совместимости. Подозрительные люди говорят вам, что у них есть копия ключа от вашего офиса. Вы же не вставите новый замок в соседнюю дверь, оставив в основной старый. Даже если будет куча тех, кому вы не смогли сразу выдать новый ключ. Так и тут. Если сломали щиты, то либо в проде появляются сразу две системы: новая и старая, и постепенно идёт миграция пользователей из уязвимой в защищенную версию. Либо мы всё ломаем и есть только новая версия и те, кого мы не обслуживаем до обновления. И тут вы опять упрётесь рогами в те же ворота SLA о доступности системы.

Эхо из прошлого.

Кстати, о доступности. Вы ведь понимаете, что доступность для пользователя системы с облачным сервисом будет равна устойчивости машины, соединения, электроснабжения и только потом эти хвалёные 99.99999. Заказчика мало волнует то, что где-то в облаке всё работает, если конкретный человек в конкретном офисе не сможет этим воспользоваться. Так что объясните это хорошо своим коллегам (на пальцах, как у якудза), которые будут подписывать. Самые простые для понимания примеры в комбинаторике монетки и кубики: У нас есть несколько кубиков, каждый на 365 граней и представляют собой доступность или надежность инфраструктуры в годовом масштабе. Подставляем данные, я люблю использовать полу-реальные данные со своего лаптопа на примере доступа к электронной почте некий облачный жи-mail. Открываете логи раутера, журнал оси и показываете пару записей о перезагрузке или разрыве соединения, а потом экстраполируете на месяц и год. Допустим за последний год у нас не было электричества 17 часов, лаптоп был в ремонте 30 часов, проблемы с соединением 4 минуты в сутки, а это 24 часа в год. И последний кубик недоступность самого облака, которая будет не больше часа в год. Так как любая из этих проблем означает отсутствие доступа к мейлам, то шанс проверить жи-почту в прошлом году был:

availability-probability

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

Ещё разок вернёмся к пункту 10 в таблице требований. Что конкретно он означает: интервал синхронизации или временной лимит работы в оффлайн? Двусмысленность в контракте лучше не допускать. Если вам повезло, и компания аудитор выступает арбитром во время всего периода развёртывания, то это уменьшит риск разночтений. Аудиторы страшный враг вашей компании и ваш хороший друг. Они будут мешать эффективным менеджерам игнорировать заявленные процедуры и не применять продемонстрированные процессы, но зато смогут помочь объяснить клиенту сложность некоторых требований и прийти к компромиссам.

---

Продолжение. К предыдущим постам и карте цикла.

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

Unus pro omnibus, omnes pro uno

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

Agile development concept

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

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

Architecture on feature map

Возвращаясь к первой статье цикла, ещё раз озвучу своё мнение о назначении архитектуры. Это оптимальный путь решения задач бизнеса. При выборе паттернов проектирования, методологии работы, технологий и фреймворков, мы всегда получаем набор функций и решений, которые работают из коробки и набор ограничений из табакерки. Ещё до финальной подписи в контракте на души разработчиков, вы должны были перепроверить всё, что заявлено. Значит основная парадигма у нас есть. Что-то типа: микросервисы в облаке с разбивкой по DDD с локальным клиентом на Java. Полезность правила измеряется количеством исключений. Так что чем меньше перекосов в сторону монолита на клиенте или костылей вокруг облака тем лучше. Тут никакого откровения нет. Но, всё же не хочется быть автором ещё одной пустой статьи из серии мы в компании Х решили всё сделать по У и у нас всё получилось. Ведь я-то как раз и хотел в статьях показать путь, которым приходят к выбору У и как даётся тот самый success story.

Как вы, возможно, читали ранее выбор часто делают за вас. Технологии - из того, что знает команда, методология тоже какая уж есть в вашей корпорации, провайдеры и стандарты обычно определяются заказчиком как одно из требований тендера. Вам же достаётся игра в Counter Strike. Пытаетесь обезвредить бомбы, которые уже заложены. Особенности работы с большими предприятиями я уже описывал. Так что сам по себе пазл не сложится. Облако и микросервисы стандарт де-факто и, почти наверняка, вас не миновала чаша сия. Такие системы всегда обладают атрибутами AP. Значит стоит определить какие узлы требуют CA.

Энтерпрайз системы в основном рассчитаны на использование сотрудниками компании для автоматизации процессов. Зачастую процессы критические и производственные. Значит нужно чётко понимать, что должно работать вне облака. Почтовое отделение, заводик или магазин должны продолжать обслуживать даже, когда облако не доступно (это не облако упало, а ваш клиент потерял соединение). И данные на месте нужны актуальные (тот самый СА вариант). Если мы возьмём за пример систему управления логистикой, где у нас есть куча грузовиков развозящих товары по дорогам страны, то понятно, что никакие изменения данных в облачном диспетчере не изменят содержимое кузова. Ну и совсем не хочется, чтоб этот грузовик простаивал, если у него нет связи с сетью. Значит его локальная система должна иметь возможность учёта товара, просмотра маршрута и управления исключениями, без которых в реальной жизни никак. Глаз в облаке будет довольствоваться данными последней синхронизации и предполагаемым прогрессом (эвристикой текущего состояния). Заявленные микросервисы на планшет водителя устанавливать видимо тоже не стоит. Они уместны в центре управления, высоко в облаках, там, где вершина корпоративной пирамиды. Но процессы и данные у центра и аппликации водителя будут перекликаться процентов на 70. Это как раз и создаёт предпосылки к путаницам с распределёнными и модульными монолитами. Нежелание повторяться приводит к сильно связанным громоздким сервисам и полурабочему зоопарку клиентов.

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

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

Ошибки молодости

Ну и как найти и учесть все подобные случаи заранее? А никак. Архитектура большого проекта похожа на школьные опыты по биологии. Там, где рассматривают кожицу лука под микроскопом. Сначала вы смотрите на всё со стороны и добавляете контрастную жидкость. Потом вставляете в микроскоп и настраиваете свет, пытаясь остаться в границах на минимальном приближении. И лишь найдя цель, меняете увеличение на максимум фокусируетесь на деталях. То есть сначала вы делали блок схему, а потом перед непосредственной разработкой будете делать архитектуру каждого блока, заполняя его деталями. По необходимости будете добавлять всякие flow и sequence они легче всего воспринимаются всеми участниками процесса разработки. Так что в отличии от строительства, вы начинаете разработку с наброска, а детальную архитектуру получите лишь в конце. Поэтому так полезны, хоть и не популярны, большие UML пакеты, позволяющие ссылки на диаграммы и вложенные чарты. Разработка это drill down от blue-print до detailed architecture.

Agile architecture concept

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

Всё, что нужно делать вручную, будут игнорировать так или иначе. Начало проекта начало автоматизации. Тут и юнит тесты (для правильного дизайна и возможности рефакторинга), и интеграционные тесты (для стабильности проекта и уменьшения time-to-market), и метрики кода (всевозможные KPI) всё часть CI-CD. Игры в микросервисы с ручной настройкой и развёрткой оставим мазохистам. Нам необходима команда DevOps. Формально или нет, но кто-то должен быть ответственным за правильную конфигурацию и установку среды. Среды разработки, среды проверок, среды интеграции и т.д. Иначе в будущем вместо среды вас будут ждать суббота и воскресенье разработки и проверки. В производственных системах редко можно найти изолированные бизнес-кейсы. Все микросервисы должны будут взаимодействовать друг с другом и между ними будет явная или не явная зависимость. Устранить этот недостаток можно еще одним уровнем абстракции! Cервис оркестратор сервисов. Тот, что вызывает цепочку других сервисов, чтоб обеспечить необходимый результат.

Delivery service orchestrates domain services in business flow

Вернёмся к нашему грузовику. Водитель хочет начать маршрут. Для этого необходимо: получить квоту на топливо, заправиться, погрузить товар, подтвердить погрузку, составить маршрут, сообщить на точки отгрузки предположительное время прибытия и так далее. Если каждый этап станет отдельным сервисом, то клиент будет отвечать за бизнес. А хотелось бы чтоб он был как можно тоньше. Удобно группировать несколько таких шагов в один процесс и вызов. Сервис заправки он проверит маршрут, квоту и авторизирует заправку. То есть последовательно запустит 34 микросервиса (с десяток API вызовов и сохранить состояние между ними). Конечный автомат. Плодить такие сервисы бесплатно тоже нельзя. Стоит создать жирненькие мета-сервисы объединяющие кросс-домейн процессы, вместо того, чтоб рулить всем из фронта. Не легковесные они, потому как знают многое о многих и строят сложные процессы взаимодействия. Однако связь односторонняя. Собственно это простой медиатор. Основная причина не раздувать клиентскую часть лежит в разнообразии таких приложений с однообразием и стандартизацией процесса. Абсолютно тот же функционал должен быть доступен в каком-нибудь легаси винформ монолите, нативном андройд клиенте, который кто-то запилил вашему заказчику пару лет назад и новой веб-аппликации из вашего пакета. Очень удобно все три приложения заставить обращаться к одному сервису, сделав миграцию из legacy в nextgen быстрой и легко управляемой.

Помимо планирования есть еще и проверки того, что план соблюдают. Настройка правил статистического анализатора кода и внедрение проектных тестов (solution unit-test), на мой взгляд, задача архитектора. Что такое проектные тесты? Это жесткие правила ломающие билд при нарушении, написанные в виде юнит теста или плагина к какому-нибудь сонару. Примеры подобных тестов:

Минимальное покрытие тестами в определённых модулях

Ограничение по количеству заигнориных тестов

Тест на то, что тест с ограничением тестов в игноре не заигнорин

Список запрещённых референсов (например уровень бизнес-логики не должен знать о типах в базе данных)

Список разрешённых референсов (допустим open source и legacy библиотеки)

Разрешённые типы файлов (к примеру файлов .sql не должно существовать)

Naming и структура проекта (если должно быть 3 слоя и каждый отдельной библиотекой, а тесты заканчиваться на _Test то будьте любезны)

Парсинг и проверка скриптов на соответствие (например скрипт конфигурации должен создавать одноименную запись и в параметрах окружения и в файлах)

Минимальное количество строк лога в каждом классе (если актуально)

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

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

Теперь пора строить план. Что вы должны выдать в качестве необходимого функционала вам сообщат все заинтересованные участники. Надо понять как много (или мало) останется на инфраструктуру. Все Agile, но только, когда им удобно. Выделить месяц на создание основы проекта без деловой логики/функционала, почему-то не хотят. Не достаточно прозрачно. Или сложно тестировать. Все уверены, что основа проекта закладывается с самой сложной формы в UI. Вот gateway ваш, безопасность и мониторинг можно и позже их же всё равно никто не видит. А заказчику нужно что-то показать. Так что опять нужно будет продавать необходимость и своевременность. Как обычно апеллируя к тому, что увеличение числа процессов и компонентов прямо пропорционально стоимости внедрения 3-х С - сквозных системных служб. И, как всегда, создаётся впечатление, что это понимаете вы и пара инженеров, но не управленцы.

Если всё получилось, то земля, прощай и в добрый путь.

---

Будни разработчика. Цели определены, направления выбраны, задачи разжеваны. Нужно просто писать код и жевать кашку. Что может скрасить серость и однообразность существования? Конечно же daily standup - шоу, в котором есть место для каждого! Ну вот эти вот неожиданные я посмотрел архитектуру и там ошибка или вот я добавил новый модуль, который нам может пригодиться в будущем ну и, конечно, я сделал всё проще и быстрей. Мы ведь именно ради этого делаем все церемонии груминга и планирования. Чтоб как бы подготовить почву и дать всем время посидеть молча и подготовить эти панчлайны на конец спринта. А самое обидное, что, потратив столько усилий, на сам стендап вы обычно не попадаете и панчи вам передаёт ваше начальство.

https://www.flickr.com/photos/cosmic_flurk/5712236914@CCL

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

Дальше отсеиваются разработчики и в следующий тур идут только тимлиды. Они более практичны и рассказывают о своих успехах и как всё по плану, а проблемы выносят в оффлайн. Сухо так и без шуток. С dev. менеджером обычно всё позитивно, если менеджер сам не станет копать или не возникнет подозрение о том, что дедлайн слишком близко к носу. И так как начальник - человек занятой (его каждый раз кто-то занимает, но, как ни странно, каждый раз и отдаёт), команд много и проекты глобальные, то представитель от каждого сайта (ротация среди лидов) подключается к общему митингу, куда обычно и приглашают архитектора. Это самые бесполезные пол часа. Каждый уже пару раз рассказал свою историю и пережевал проблемы (а тут, видимо, как и с шутками: проблема, повторенная дважды, перестаёт быть проблемой). Вдобавок говорить то на английском надо, который для большинства неродной и куча акцентов Короче, каждый chosen one пытается сказать одно-два предложения, так чтоб не дай бог не задали вопросов. Как на приёме в налоговой.

Сетка игр в дейли

В итоге каждая команда поделилась своими проблемами только с собой. Оставшись внутри закрытого спектра бизнес-задач и решений, которые знакомы всем её участникам. Я не против психотерапии, но если у вас проблема и вы можете решить её внутри команды, то зачем ждать планёрки? А если не можете то, чем поможет её озвучить в том же кругу? Но я не менеджер и даже не Agile тренер мне не понять. Я - Винни Пух и по утрам хожу в гости. К кому-нибудь. Желательно без приглашения (иначе рискуете услышать заученный текст на английском) на ту самую первую сцену, где профилактика будет стоить дешевле лечения. Это здорово экономит время, так как альтернативой будет просмотр коммитов. Код ревью тот же рыбий жир. Может и полезно, но никто не любит. Любят мёд. Но мёд, как известно, странный предмет он есть лишь там, где тебя нет.

Поправка на ветер

В чём же будни архитектора, помимо кофе и рисования? Ведь многие считают, что гнездо архитекторы вьют только из одноразовых стаканчиков в местах большого скопления whiteboard-ов. Конечно же в ловле личинок bug-ов! В первую очередь, конечно, интересуют ошибки проектирования. То есть свои же собственные промахи. До начала разработки архитектуру семь раз замеряли, но когда приходит время отрезать, выясняется, что попасть в метку тяжело, пила не та, то брус не тот. Все стройные теории начинают сползать с вакуумного глобуса. На этапе разработки первичной версии начинают выясняться все детали, которые попали в финальную версию контракта. Самые главные: дата и точный спектр функционала первого демо для клиента.

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

7 фишек этому господину!

Ад у каждого свой. Мой похож на ежедневные диспуты с начальниками разных отделов, каждый из которых предлагает вместо твоей глупой инфраструктуры, давай сделаем анимированные кнопочки. Случалось же слышать: а юнит тесты точно нужно писать? А может можно как-то без них? или нам же сейчас не нужно это твоё скалкобилити, а красивый интерфейс это лицо продукта. Хорошее лицо тоже важно, но этот орган плохо поглощает кинетическую энергию и при встрече с бетонной реальностью лучше приземлиться на пятую точку. Особенную нишу занимают вот тут 20 дней на безопасность выделено, нужно сделать за 10, чтоб ещё пару фишек втиснуить из бессмертной серии а семь шапок можешь?. Мне всегда сложно объяснить кому-то почему же 2+2 = 4. На сложные вещи аргументация всегда находится, а как объяснить то, что ты считаешь базовым, да еще и когда экспериментально доказать за 5 минут не получится.

Флешбэнг

Чтобы понизить градус ада приходиться заниматься презентациями, которые бы наглядно показали как у нас всё работает и почему. Хочется, конечно, Босха, но приходится сводить простые зарисовки со стрелочками. Анализировать бэклог, искать пересекающиеся требования и показывать, что кнопочки сейчас по затратам равны кнопочки завтра, а безопасность сейчас намного дешевле безопасность завтра. Строится цепочка требований ведущих или исходящих из кнопочки и такая же для требования безопасности. Так как бизнес-требования обычно не пересекаются, то цепочку таких требований легко двигать в плане вперёд и назад. А значит и цена будет неизменной. Инфраструктура же пронизывает все модули и цепочки, а значит если завтра будет в 10 раз больше модулей, то будет и в 10 раз больше интеграции/внедрения и проверок (важная статья расходов и времени). Кто бы мог подумать!? И обязательно гуглите что-то из серии цена ошибки безопасности в своём промышленном/деловом секторе. Для производства всегда хорошо работает пример Иранских центрифуг. В финтехе или ритейле примеров полным-полно. Хорошая страшилка лучше любых формул. Детей пугают сказкой про волка, а не расчётами семейного бюджета (хотя последнее может быть намного страшней).

инфраструктура шашлыкаНа моей памяти

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

Мой know-how в этом процессе направляемый мозговой штурм. У вас есть готовый вариант архитектуры модуля. В моём случае это значит, что определена модель (абстракции) и контракты (данные) и есть сопутствующая диаграмма взаимодействий или сущностей. Так вот эту диаграмму я начинаю строить с разработчиком, скармливая ему требования и проблемные аспекты так, чтоб он посмотрел в конце на моё решение и сказал классно мы с тобой придумали!. Ну ещё бы.

Работает это примерно так:

Нужен модуль, который получает пакет цифровых документов и мапит их в базу. Разработчик сразу предлагает какой-нибудь pub-sub, асинхронные (так почему-то 80% людей называют параллельные процессы) таски и пару микросервисов. Куда же без них.

первый предложенный вариант

Теперь надо подхватить его под руку и вести туда, куда хотите вы. Закидывается проблема и предлагается решение, которое у вас прописано в архитектуре. Как-то так: Хорошее решение, но если у нас будет асинхронный маппинг, то возникнут проблемы совместного доступа. А что, если вместо параллельности мы сделаем последовательность?.

второй предложенный вариантПро параллельность

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

конечная

За шага 3-4 мы уже достигаем желаемого результата. В отличии от варианта, когда вы просто объясняете почему стоит сделать именно так, вы не лишаете человека самого важного поиска решения. Разработчик не стенографист и не стал экспертом потому, что просто быстро записывал за кем-то построчно. Если лишить его загадки, то работа может вызвать протест и кучу отрицательных эмоций. С другой стороны, он не знает всей картины. Ни того, что и как будут делать в других командах, ни того, что запланировано на полгода вперёд. В этом основная причина существования должности архитектора широкий и далекий взгляд на проект. Но ничего не получится, если ваша архитектура не обоснована требованиями. Нечем будет вести разработчика, да и незачем. В таком случае лучше честно партбилет на стол. У нас с этим строго. Это по утрам я Винни-Пух, а к концу дня я свинья с ружжом!

архитектор бьёт чучелом ружья вымышленного леопарда

И стрелять всегда есть в кого. Пока все усердно пишут код нужно следить, что б всё неусерднулось. Тут на помощь нам всякие индикаторы и статические анализаторы кода. Делать метрики для программистов удел менеджеров. Я лично озабочен метриками кода. Индикаторы здоровья проекта:

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

• Длинные функции и классы не плохой индикатор поспешной работы и костылей. На начальном этапе такого быть не должно.

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

• Нарушение конвенций тоже стоит заавтоматить и следить. Закладывается фундамент дома, в котором нам всем жить долго.

• Много статики (классов, методов, полей), обычно, проявления антипаттернов.

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

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

Для подготовки к следующему этапу необходимо выстроить хороший механизм логирования. Желательно на два уровня один с понятной историей для бизнеса, а второй для технического анализа, что же всё-таки навернулось. Когда со стадии демо мы шагнём, пусть и в ограниченный, но production, то там будут первые кострища и охота на ведьм. Наблюдать в полнолуние как кто-то седеющими руками набирает код прям в проде плохая примета. По возможности старайтесь избегать этого. Так что одним стримом пишем: пользователь ****341 запросил функцию Поиск Заказа с аргументом 3480-4341-1334. Результат: не найдено. На этот лог сядет саппорт, когда процесс встанет. А второй стрим со стеком, сервисами и всеми деталями (опять-таки, кроме тех, что нужно замазать ради безопасности или для сохранения личных и коммерческих секретов). Тут уже пойдут разработчики, когда процесс ляжет. Логи делать необходимо с самого начала. Они всегда нужны вчера, когда всё случилось, а вот завтра от них будет мало толку. Клиент как-то не любит слышать: У вас тут вчера производство встало, а мы не знаем почему. Но когда встанет в следующий раз у нас будет больше данных для анализа!. Хотя в некоторых компаниях лишь под угрозой штрафов начинают понимать, что стоило вложиться сразу в аудит и мониторинг да начинают чесать головы (те в которые едят и те на которых сидят).

Мысль вслух

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

---