Продолжаем. К предыдущим постам и карте цикла.
Ну, первый шаг то уже сделан. Куда еще не совсем понятно, но откуда, доподлинно известно - из точки покоя и равновесия. Самое время разобраться почему тут как-то скользко и липко. И кто все эти жужжащие создание, которые слетаются к скелету рыбки Мандельброта, которую мы назвали пропихуемой архитектурой.
Часть шума создают потенциальные клиенты. Они шуршат RFP, трясут золотыми яйцами государственных куриц, тыкают в календарики и всегда улыбаются. А чего им не улыбаться то? За ними под запах курятины вьются роем адвокаты, консультанты, маркетологи, аналитики и анаболики. Что сразу бросается в глаза – это возраст. Его просто нет. Вот в стартапах все такие на 20, начальство под 40 и сразу всё ясно без цветовой дифференциации штанов. Тут же вас может встретить Багира, только что закончившая институт и возглавляющая отдел предпенсионных бандерлогов. Суровый Балу вяло шуршит пылесосом. Каменные статуи с галстуками смотрят не мигающим глазом сразу в 3 монитора. Блестящий Ка застывший между 40 и бесконечностью с бесом в голове и сединой в бровях встретит вас в большом овальном кабинете с видео камерой и конференц-связью. Кто он и что у него за должность вы будете гадать до конца встречи.
И так, где же мёд и о чём жужжат дикие пчёлы? Особенностью Энтерпрайза всегда является размер. Он таки имеет значение. Наращивается он по-разному и это сильно влияет на структуру. Где-то это слияния, где-то поглощение, а где-то кооперация. То есть иногда голова одна, а иногда десяток и по всему миру. Но всегда есть общая черта – многослойность. Матрица или иерархия – не столь важно. Главное понимать, что любой контакт с внешним миром запускает процесс внутренних коммуникаций вверх. И вверх – это как бы против течения. Сверху вниз все стекает очень быстро. Вот, кстати, и ответ почему так скользко. А вот вверх – только под усиленным давлением.
Свежий пример
Тут недавно закинули на gap analysis требование потенциальной системы для будущего тендера. Это оказался экселик с чеклистом на 600 пунктов с названием СистемаБудущего20150512. В мете документа тоже 2015. Да, компания поняла, что их система устарела и начала готовиться к тендеру 5+ лет назад, но пока еще не созрела. Случай, конечно, исключительный, но показательный.
Так вот Эйнштейн явно не просто так пришел к своим теориям. Время в энтерпрайзе относительно. Презентация проекта ровно 2 часа? Перед вами поставят песочные часы и будьте любезны покинуть помещение чуть раньше. Вы послали срочный запрос на уточнение деталей тех. задания? Когда-нибудь вам ответят. Пилотная стадия проекта ровно неделю и «только вон на тех двух машинах»? Её будут обсасывать не меньше месяца в 20 местах на разных континентах. Ну и что, что просто демо, и в вашем часовом поясе сейчас 5 утра – тут вот кнопочка неправильно называется. Короче, ваше время и их время – это разные сущности. Не успели донести мысль или задать вопрос – пишите в спортлото. Шанс ответа вовремя и по делу примерно равен выигрышу. Если же где-то на вершине пищевой пирамиды возникнет вопрос – он упадёт на вас стремительно и точно.
Значит первоочередной задачей становится поиск ключевых фигур. Среди всего роя нужно найти людей опытных и технических. Они не обязательно будут присутствовать непосредственно на встречах. Но с каждым вашим вопросом, вы будете замечать, что улыбающиеся люди лезут в телефон или имейл и выуживают информацию оттуда. Вам нужны те люди, которые эту информацию туда кладут. Нужен святой грааль, за которым потянуться рыцари этого королевства, а не пажи и придворные. Обычно грааль стоит искать в DR. Пара-тройка вопросов о поведении в непредвиденных обстоятельствах и пошлют за спецами. Из них нужно вытянуть как можно больше инфы и еще контакт наладить. Если вошедший протянул тебе визитку, то скорее всего это бесполезная улыбашка. Потому что у спеца на лице будет транспарант, что его оторвали от IDE ради какого-то клоуна, который явно случайно собрал услышанные где-то слова в призывающее заклинание. Хороший инженер не любит context switch. Поэтому не курит и пьёт чай из огромной кружки.
Чем выше пирамида, тем дальше голова от мозга. В огромных компаниях у каждого свой узкий коридор без дверей и окон. Тот, кто принимает заявку на тендер и тот, кто эту заявку рассматривает – могут оказаться в конкурирующих отделах. Тот, кто составляет требования, скорее всего никогда к системе не прикоснётся. А зачастую даже никогда и опыта подобного не имел. Точнее сказать «имел» он всех тех, кто будет этим пользоваться. Например, директор IT отдела будет вести тендер на мобильные устройства для подсчёта товара на складе помидорок. Почему именно он? Ну потому, что над ним сидит вицепрезидент отдела продаж, которому доложили, что неустойка возникла из-за неправильной оценки количества доступного товара. И вот VP решил поискать сейлфарс-копросоциальной сети: «инновация» и «облако» (нам, специалистам, без облака никак низя) и попал на IT. И пофиг, что IT просто хранит в облаке фотки с корпоративов или отвечает за «офис 256». Поэтому, тому IT директору нужно от вас только, чтоб он ни за что не отвечал и хоть что-то понимал. И так как эта частая история, то мой вам совет – самые важные стрелочки в диаграммах на первых этапах – коммуникации. Какой порт открыть и какой будет модель деплоя на железки – вот то, что он знает и хочет видеть. За безопасность отвечает тоже он. И, как вы уже угадали, ему пофиг на ассиметричное шифрование. Главное, чтоб порт 443, пару сертификатов и базу данных с бэкапами побольше. Поэтому и подаем обычно что-то типа наскальной живописи. Примитивно, но сюжет понятен.
Страх и ненависть в Enterprise без которых рамки архитектуры будут не полными:
Нет единого контакта, чтоб получить больше деталей. Приходиться заводить картотеку. Лишь в паре проектов мне довелось работать с тех отделом клиента сразу. Вот прям архитектор с архитектором. В остальных надо собирать данные для интеграций и интерфейсов по кускам.
Время – деньги. Пропустили сроки – прощайте. Лучше без деталей и частично, но подать. Если приглянулось, то с вами свяжутся. Поэтому как можно меньше копайте в глубь. Отсутствие деталей – не только ускорение, но и свобода их выбрать дальше.
Размер имеет значение. Если ваша система требует установки на клиентские машины, то учтите, что их может оказаться тысячи и всё старье. Да, даже Windows XP/CE в наладонниках какой-нибудь гос. структуры. В таком варианте заявленный TLS 1.3 выльется в рукописное шифрование и всякие termination proxy.
Всё что вы скажите может быть использовано против вас. Протоколы бесед и совещаний и разговоры с адвокатами. Вы как бы для мажора сказали, что тут realtime, а потом посмотрят в конечном продукте, что есть фиксированная задержка и приедут обсуждать штраф. Из личного опыта было: обсуждение падения кластера в присутствии адвокатов с обеих сторон. А в «соседнем» проекте сначала уведомительное письмо о большой адвокатской конторы, что не соответствие SLA в производительности станет причиной разрыва контракта. Не подтянули что-то по производительности и волна увольнений. А дело там совсем не критичное было. Просто клиент хотел спрыгнуть и нашёл повод. Так что no commitment и никакого fine tuning. Не знаете точно потянет ли один сервер или нужно 2 – укажите в заявке, что необходимо 2, но может меняться в зависимости от…
Vendor lock – ненависть во все поля. Энтерпрайз такое не терпит. Как можно больше стандартов и открытых протоколов.
Vendor lock – очень не любят. Поэтому раздельные тендер на поставку, обслуживание, поддержку и тд. То есть вы можете выиграть в нескольких или в одном. Зачастую вы поставляете софтину, кто-то другой железо, кто-то третий будет это ставить и обслуживать. Лучший вариант, когда для on-prem у вас чёрный ящик – ваша компания не продаёт софт отдельно. Но всё равно поддержка будет не у вас. Не рассчитывайте на определённую версию софта и что не будет конкуренции за ресурсы. Будьте stateless где только можно.
Vendor lock – одно из самых важных. Даже открытые технологии бывают связаны с вендором. Допустим с Google. И такие вещи не примут в каком-нибудь Китае.
Мой компас опыта указывает строго на запад, а потому насаживать ли его на ваши реали – дело личное. Сценарий обычно прост и неизбежен. Маркетинг и продажи находят потенциального клиента, собирают документы и совещания, чтоб определиться, кидать ли гарпун. Это было в прошлом выпуске. Теперь надо заявить о себе! Нет, если вы крутой специалист то, наверное, вы еще подождёте. Пусть вон менеджеры по продажным сами разбираются. И они всегда разбираются. Их ведь работа пройти все уровни до подписания, а там и босс, бонус и финальные титры. Прикинь, а им ничего разрабатывать не надо! Они даже не всегда понимают, о чем тендер. Поэтому обещать и торговаться они будут по стратегии наибольшей личной выгоды. То есть как можно больше, в минимальные сроки и дорого (именно от «дорого», а не от «что» и «когда», зависит их премия). Поэтому сначала в вашей корпорации ставят план отделу продаж, а потом, когда его выполняют и перевыполняют, и выясняется, что 9 программистов не смогут родить за месяц, потому что они все одного пола. Тогда на presale и начинают отправлять в нагрузку бизнес-аналитика и архитектора.
Вообще, в корпе связь между бизнесом и архитектурой размыта для стороннего наблюдателя. Но на самом деле всё просто. Аналитик не умеет в код. Нет, ну какую-нибудь «лунную сонату» и может уметь, а вот Мурку скорее нет. Разве что он мигрировал из инженеров в тёплое место, где ни за что не отвечают. Полный бизнес – это как кладбище слонов, куда архитекторы переходят перед пенсией. Но пока всё наоборот. Во-первых, вы за всё отвечаете. Так как в мире полупроводников, вы единственный проводник между желанием клиента и конечны продуктом. И еще кот. В смысле код. Ну как там: «Видел я код без архитекторов, но вот архитектора без кода…»
Сложность бытия проводника обычно в том, что ожидание – это проводник электричества и сигналы непрерывно текут в оба конца, пусть и звучит это иногда для наблюдателя как подключение модема. На самом деле вы проводник в поезде и разносите чай от головы к хвосту, проходя через вагон ресторан и полностью теряя связь с предыдущем вагоном, как только вошли в тамбур. Все понимают, что без чая хуже и самим его делать не всегда быстро и вкусно, но особой любви не будет. Машинист всё время думает, что он тянет слишком много. Он видит и слышит, что творится в ближайших вагонах, но то длиннющий хвост – явно балласт. Сбросить бы его и взлететь! О том, что в этом составе вагоны не тянут, а толкают, он не думает. Поэтому он любит добавлять вагоны в голову – они-то точно несут полезную нагрузку. Он её видит лично. Вагон-ресторан близко к голове и чай с сахаром оттуда разносят во все стороны, а загружают лишь на коротких остановках. Так как самые жирные остановки - не по расписанию, то и забота – оберегать запас. Потом вагончики менеджментов. Продажи за коммунизм – всем чаю, много и быстро! Вы их не почему-то не поддерживаете. Поддержка и инфраструктуры любят подстаканники и стаканы с готовым чаем, чтоб сразу пить. А все вот эти ваши чаи в пакетиках, сотня сортов, 5 вида сахара с 3 форм-факторами, да ещё эта влагочувствительность при хранении. А уж одноразовые странички, которые надо раздавать и утилизировать. Короче, раньше чай был вкусней и проводник знал свое место. В вагоне PM любят только кипяток и маленькими глотками. И заварку подмешивать в каждый глоток, потому что, вдруг захочется другой сорт или вообще кофе. А вы тут с вашими предварительными заказами и невозможность сделать холодно-горячий кофе-чай с безмолоком-сахарнетом. Dev менеджеры любят, чтоб им приносили много и всегда. Но не учили, как пить и когда. И не критиковали за то, что чай проливается, если его переливать в карман, пить без стакана, напёрстками, стоя на голове. Что сливать остатки в один стакан – это не новый сорт, и есть сахар – это не то же самое, что пить чай. Потом синьоры-эстеты. Они обязательно должны заваривать сами и не любят прозрачные стаканы, в которых всё видно. В общем, вас действительно ждут только в хвосте, где сидят джуны, но их нужно поить каждого отдельно и ложечкой. Ну и, конечно, своего вагона у вас нет.
Зачем всё это, и что тут от архитектуры? Как я уже заикнулся, архитектура нужна для того, чтоб ответить на требования бизнеса. Но помимо необходимого функционала есть еще и окружение, куда всё это должно вписаться. Мне не довелось работать в больших аутсорсах, а значит и смотреть на всё я буду с огромной продуктовой компании. С историей, рынком, продуктами и инерцией. В головных вагонах понимают, что рельсы уже не те, но свернуть с них то тяжело. Поэтому всегда стараются переобуться на ходу. Значит вы работаете не с чистым листом, а линейкой готовых продуктов, которым уже не помогут стероиды. Или отрываете смежную нишу в продуктовом ряду. Но неразрывно связанных. Разница веса большого клиента и обычного клиента – миллионы зеленых причин. Имя, которое носит ваша компания и её история – вход на рынок больших. То, что вы, возможно, не знали если не были на этом рынке и необходимо учесть при дизайне и позже в архитектуре:
Обычный клиент получает ванильку. Энтерпрайз клиенту туда добавят шоколад и орешки.
Функционал и вид могут сильно отличаться. Ваша задача не пойти лёгкой дорогой и создать бранч под клиента или утыкать всё ифками. Компания не хочет больше расходов на тесты и модификацию, хрупкий код и поддержку. Чтоб остаться с как можно меньшими частями специфичного клиента не плохо было бы использовать заменяемые модули, enrichment, event driven, плагины, no-code.Обычный клиент берет мороженку, а крутой укажет, кто подаст. Клиент реально может пройтись по списку и выбрать кто будет работать и управлять разработкой. Прям проходят по резюме ключевых и отсеивают. Повод для отсева в основном опыт и конфликт интересов. Либо недостаточно хорошо, либо задействован в проектах с конкурентами. Не рассчитывайте при выборе технологий на конкретных людей – они могут попасть в опалу.
Обычный клиент интегрирует вашу систему, а к господину клиенту интегрируетесь вы. Вам могут поменять не только контракт, но и направление запроса. Заранее рассчитывайте на интерпретаторы и адаптеры. Особенно если давно и жёстко сидите на микросервисах. Distribution tax может не реально вырасти.
Обычный клиент имеет один бизнес, а этот много и везде. А значит нужно учитывать географию, доступность коммуникации и регуляции. Быть может технически нереально раздавать псевдованильку по свету и всё-таки придётся как минимум делать отдельный деплой. С облаками можно наесться «шоколада» пытаясь привычную вам бизнес модель натянуть на множественные часовые пояса, валюты, культуры и не логичные законы (а они почти всегда не как не вписываются в уже имеющуюся картину мира корзины готовых продуктов вашей корпорации). И те же облачные провайдеры имеют разный набор инструментов и цен в разных регионах.
Обычный клиент ест, когда дают. Клиент с большим аппетитом выбирает когда. Так что, если вы привыкли что раз в квартал у вас обновляется функционал и все на него переходят, то тут может быть совсем не так. Во-первых, могут потребовать переиграть бэклог и что-то доставить быстрее и не с плановым выходом версии, а до определенной даты. И, конечно, помимо того, что нужно поддерживать версии, тут их может понадобиться не одна. Огромная организация не будет обновляться быстро. Я раньше работал с 2-3 версиями в проде, а тут их раза в два больше, даже при полной обратной совместимости. Поддержка кода и возможность тестирования становятся основным приоритетом.
Обычный клиент будет рад, когда попадётся орешек, а жирный следит за диетой. Вам будут указывать какие фиксы и фитчи войдут в релиз, а какие нет. Тут не грех еще раз напомнить про предыдущий пункт. Зачастую инфраструктуру протолкнуть в релиз тяжелее. Клиент боится больших изменений. Так что старайтесь делать всё по кускам и с конца в начало – forward compatibility. Ну и decoupling, decoupling, decoupling.
Помните Vendor lock? Не рассчитывайте, что ваша система будет полностью в ваших руках. Если это on-prem, то и вообще доступа не будет. Учитывайте, что дебажить надо будет «по логам», а поддержка будет оперировать с огромной задержкой. Описание проблемы вы получите частичное и запоздалое. Многоуровнивые логи, чёткие сообщения об ошибках, система предупреждений (warnings) и развёрнутого healthcheck. Инструменты для сбора необходимой информации. Всё, что часто называют – production readiness, должно быть частью архитектуры.
Опять простыня. Вкратце: подают заявку на тендер и начинаются первые взаимные прощупывания. В этих джунглях свои законы. Перед заказчиком – всё вовремя и как можно меньше обязательств. Внутри своей организации придётся брать ответственность за решения, которые принимают другие. Поэтому необходимо им «помочь» сделать правильный выбор. Планируйте, как угодить большому клиенту, не подставляя других и главное себя (лично и компанию). Тезисно:
a. На других посмотреть
i. Возраст организации не показатель опыта и профессионализма
ii. Время всегда работает против вас
iii. Нужного спеца – лови на живца!
iv. Следи за собой – будь осторожен.
b. Себя показать
i. Не оставлять предпродажу на самотёк
ii. Вы часть той силы, что хотит добра, но…
iii. Окружение формирует архитектуру
