Software architecture

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

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

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

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

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

От теории к практике. Линия на картинке плевое дело. А как насчет реальной архитектуры то? Вот тут бы хотелось немного поподробней. Тем более, что картинка глупая. Если фича нужна, то её запилят. Как и положено, зеленой пересекающей параллельной линией прозрачного цвета. Поэтому и архитектуру нужно гибкую и разноцветную. Но сначала прямые линии на голубом листе и ярылчки с брендами. Blueprint и tech. stack. И это вообще не архитектура, а дизайн. Набросок.

Как это в Agile устроено при построении задания, так и здесь: цель, средства, что дано. Для этого шага есть много сапог. Померяв несколько, я решил быть в тренде. На одной ноге IDesign, на другой DDD. Вот только не надо мне тут про микросервисы, клиент-сервер и всякие распределенки. Мы не на этом этапе. Нас интересует то, что нужно клиенту, а не как. В старом добром UML мы бы сейчас построили use-case и block диаграммы. Нам нужно определить основных игроков и функции - расставить точки на карте. Я обычно не углубляюсь пытаюсь рисовать человечков пользователи разные, но система одна. Так что я просто отрезаю интерфейс от сценариев. Грубый план обычно - такой синий пирог с разноцветными цукатами.

Опытный инженер сразу заметит, что как-то попахивает заданием для продуктового отдела нашего супермаркета. Все вот эти Product Owner и Business Analyst должны дать те самые юзкейсы и фитчи. Хотя нет, опытный инженер вообще это читать не будет. И уж тем более кто как не он, должен знать, что архитектуру сначала надо продать своим. Начальству, инженерам, поддержке и тд. Поэтому и диаграмма должна говорить на их языке. Что же важно мне на данном этапе определить блоки, которые будут служить основой. Те, что ближе к константам, чем к переменным. Несущие конструкции. Количество стен, не углубляясь из чего они сделаны.

Продали колонны? Что теперь интересно вашим клиентам? Цвет труб! То что они увидят, только в случае серьёзного чп. Логично же. Большой и неповоротливый энтерпрайз любит, чтоб о нём говорили как о динамичном и энергичном. Так чтоб в тренде, вон с тем стратапом. Но только, чтоб надёжно. Вам нужны жужалки и стразики - buzz words. Вот тут уже надо начать набрасывать распределенные микросервисы на облако. После первого этапа все должны в курсе будет ли эта закрытая ли система, с доступом в сеть или нет, количество пользователей и срок жизни, дискретность окружения и всё такое. Это, однако, не помешает клиентам требовать cloud для системы в offline. Нет, я не преувеличиваю. И вот чтоб были автономные микромодули, но только монолитом. Актуальные и верные данные в любое время в постоянно доступной, разрозненной системе. Привет кэп! Можно обнаружить (в копилке личного опыта), что клиент в северной Африке на диалапе, лучший пинг в ближайшее облако больше 300, а хотят они реалтайм для управления дронами по видео с бортовой камеры. Инженеры, работающие с клиентами напрямую, в цирке не смеются.

Значит теперь задача набросать много звучных и цветных иконок трендовых технологий. Универсального рецепта нет, так как готовить всё равно придётся из того, что есть в холодильнике. Вряд ли вам дадут нанять новую команду специалистов. Энтерпрайз проекты живут десяток лет и года 2-3 в разработке. Так что в одну клавиатуру такое не поднимешь. Необходимы готовые команды, а у них уже есть какой-то опыт и знания. Если у вас 5 команд бэкенда пишет на Java, то переводить их Python нет не времени не смысла. Играете с теми кубиками что есть, и будьте любезны собрать слово счастье. Однако стоит всё-таки делать выбор и не пускать на самотёк. Если у вас есть клиент (UI/UX), и он не слишком мудрёный и жирный, то тут можно вставить свежачок. Лицо системы долго без изменений не живёт, да и фронтэнд технологии тоже. Так что, если актуален сейчас React бери его и найдите одного специалиста. Бэкхэнд на 10 лет вперёд требует и технологию, которая не исчезнет. Поэтому то и популярны .NET и Java. Если есть место микросервисам, то каждая команда может взять свою технологию. Но они же в том же холодильнике, так что сюрпризов не будет. Только помните, что микросервисы не всегда уместны. А иногда и совсем не уместны. Нет у вас центра и не нужно динамическое масштабирование, то может и не надо городить огород? Люди десятки лет, работавшие на поддержке монолита, не обрадуются тому, что им придётся содержать зоопарк. Они даже не понимают, что это надо выкатывать и содержать вручную в случае частного закрытого решения (on-premises project). Нельзя поехать и поменять или подключиться по RDP и залезть ручками в базу данных. А потом они всё равно это сделают через какой-нибудь джампер бастион и поменяют что-то, как-то не догадавшись, что это лишь одна из 12 баз и теперь данные всей системы не стыкуются - прощай выходные!

Немного оффтопа. Клиент как кит в океане, только старый, не грациозный, с тремя головами и вяло текущей деменцией. Но и корпорации, которые его обслуживают не лучше. У них старые связи с клиентом. Они когда-то поставляли/производили железо и пытаются видеть в софте всё те же станки. Сделали рабочий прототип фигачим еще миллион и поставляем. Долгая проектирование, потом немного допилим, в производство и на моментально на полки/клиентам. Они же всегда так делали. Как это roll-out это долгий процесс? Ведь copy-paste и в продакшн! В общем, как много нам открытий чудных Поэтому решение надо не только продать и утвердить внутри своей компании, нужно еще удостовериться, что сама компания будет соответствовать решению.

И так наша следующая диаграмма будет всё еще аморфной, но уже на технологиях. Точность компонентов и связей здесь не столь важна, а вот обоснование выбора картинок необходима. Именно здесь впервые затронут бюджет. Лицензии, специалисты, обучение, поддержка, система. Много иконок клиент радуется, большие траты клиент дуется. Есть, конечно, горячие пирожки. Не важно куда и как, но нужен Kubernetes. Даже если и нет масштабирования засуньте в автоматическое тестирование как часть CI-CD. Но иконка должна быть. Бесплатные пирожки ещё вкусней. Вам понятно, что Kubernetes будет с контейнерами Docker, но заказчик будет брызгать деньгами, если вы добавите и этот образок. И безопасность туда же прилепите https.

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

Вот где то тут я чувствую, что текста уже слишком много. Стоп. Остальные дальше просто не пройдут. Если зайдёт - буду продолжать.

Продолжаем.

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

Часть шума создают потенциальные клиенты. Они шуршат RFP, трясут золотыми яйцами государственных куриц, тыкают в календарики и всегда улыбаются. А чего им не улыбаться то? За ними под запах курятины вьются роем адвокаты, консультанты, маркетологи, аналитики и анаболики. Что сразу бросается в глаза это возраст. Его просто нет. Вот в стартапах все такие на 20, начальство под 40 и сразу всё ясно без цветовой дифференциации штанов. Тут же вас может встретить Багира, только что закончившая институт и возглавляющая отдел предпенсионных бандерлогов. Суровый Балу вяло шуршит пылесосом. Каменные статуи с галстуками смотрят не мигающим глазом сразу в 3 монитора. Блестящий Ка застывший между 40 и бесконечностью с бесом в голове и сединой в бровях встретит вас в большом овальном кабинете с видео камерой и конференц-связью. Кто он и что у него за должность вы будете гадать до конца встречи.

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

Так вот Эйнштейн явно не просто так пришел к своим теориям. Время в энтерпрайзе относительно. Презентация проекта ровно 2 часа? Перед вами поставят песочные часы и будьте любезны покинуть помещение чуть раньше. Вы послали срочный запрос на уточнение деталей тех. задания? Когда-нибудь вам ответят. Пилотная стадия проекта ровно неделю и только вон на тех двух машинах? Её будут обсасывать не меньше месяца в 20 местах на разных континентах. Ну и что, что просто демо, и в вашем часовом поясе сейчас 5 утра тут вот кнопочка неправильно называется. Короче, ваше время и их время это разные сущности. Не успели донести мысль или задать вопрос пишите в спортлото. Шанс ответа вовремя и по делу примерно равен выигрышу. Если же где-то на вершине пищевой пирамиды возникнет вопрос он упадёт на вас стремительно и точно.

Значит первоочередной задачей становится поиск ключевых фигур. Среди всего роя нужно найти людей опытных и технических. Они не обязательно будут присутствовать непосредственно на встречах. Но с каждым вашим вопросом, вы будете замечать, что улыбающиеся люди лезут в телефон или имейл и выуживают информацию оттуда. Вам нужны те люди, которые эту информацию туда кладут. Нужен святой грааль, за которым потянуться рыцари этого королевства, а не пажи и придворные. Обычно грааль стоит искать в DR. Пара-тройка вопросов о поведении в не предвиденных обстоятельствах и пошлют за спецами. Из них нужно вытянуть как можно больше инфы и еще контакт наладить. Если вошедший протянул тебе визитку, то скорее всего это бесполезная улыбашка. Потому что у спеца на лице будет транспарант, что его оторвали от IDE ради какого-то клоуна, который явно случайно собрал услышанные где-то слова в призывающее заклинание. Хороший инженер не любит context switch. Поэтому не курит и пьёт чай из огромной кружки.

Чем выше пирамида, тем дальше голова от мозга. В огромных компаниях у каждого свой узкий коридор без дверей и окон. Тот, кто принимает заявку на тендер и тот, кто эту заявку рассматривает могут оказаться в конкурирующих отделах. Тот, кто составляет требования, скорее всего никогда к системе не прикоснётся. А зачастую даже никогда и опыта подобного не имел. Точнее сказать имел он всех тех, кто будет этим пользоваться. Например, директор ITnотдела будет вести тендер на мобильные устройства для подсчёта товара на складе помидорок. Почему именно он? Ну потому, что над ним сидит вицепрезидент отдела продаж, которому доложили, что неустойка возникла из-за не правильной оценки количества доступного товара. И вот VP решил поискать сейлфарс-копросоциальной сети: инновация и облако (нам, специалистам, без облака никак низя) и попал на IT. И пофиг, что IT просто хранит в облаке фотки с корпоративов или отвечает за офис 256. Поэтому, тому IT директору нужно от вас только, чтоб он ни за что не отвечал и хоть что-то понимал. И так как эта частая история, то мой вам совет самые важные стрелочки в диаграммах на первых этапах коммуникации. Какой порт открыть и какой будет модель деплоя на железки вот то, что он знает и хочет видеть. За безопасность отвечает тоже он. И, как вы уже угадали, ему пофиг на ассиметричное шифрование. Главное, чтоб порт 443, пару сертификатов и базу данных с бэкапами побольше. Поэтому и подаем обычно что-то типа наскальной живописи. Примитивно, но сюжет понятен.

Страх и ненависть в Enterprise без которых рамки архитектуры будут не полными:

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

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

Размер имеет значение. Если ваша система требует установки на клиентские машины, то учтите, что их может оказаться тысячи и всё старье. Да, даже Windows XP/CE в наладонниках какой-нибудь гос. структуры. В таком варианте заявленный TLS 1.3 выльется в рукописное шифрование и всякие termination proxy.

Всё что вы скажите может быть использовано против вас. Протоколы бесед и совещаний и разговоры с адвокатами. Вы как бы для мажора сказали, что тут realtime, а потом посмотрят в конечном продукте, что есть фиксированная задержка и приедут обсуждать штраф. Из личного опыта было: обсуждение падения кластера в присутствии адвокатов с обеих сторон. А в соседнем проекте сначала уведомительное письмо о большой адвокатской конторы, что не соответствие SLA в производительности станет причиной разрыва контракта. Не подтянули что-то по производительности и волна увольнений. А дело там совсем не критичное было. Просто клиент хотел спрыгнуть и нашёл повод. Так что no commitment и никакого fine tunning. Не знаете точно потянет ли один сервер или нужно 2 укажите в заявке, что необходимо 2, но может меняться в зависимости от

Vendor lock ненависть во все поля. Энтерпрайз такое не терпит. Как можно больше стандартов и открытых протоколов.

Vendor lock очень не любят. Поэтому раздельные тендер на поставку, обслуживание, поддержку и тд. То есть вы можете выиграть в нескольких или в одном. Зачастую вы поставляете софтину, кто-то другой железо, кто-то третий будет это ставить и обслуживать. Лучший вариант, когда для on-prem у вас чёрный ящик ваша компания не продаёт софт отдельно. Но всё равно поддержка будет не у вас. Не рассчитывайте на определённую версию софта и что не будет конкуренции за ресурсы. Будьте stateless где только можно.

Vendor lock одно из самых важных. Даже открытые технологии бывают связанны с вендором. Допустим с Google. И такие вещи не примут в каком-нибудь Китае.

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

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

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

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

Обычный клиент получает ванильку. Энтерпрайз клиенту туда добавят шоколад и орешки.
Функционал и вид могут сильно отличаться. Ваша задача не пойти лёгкой дорогой и создать бранч под клиента или утыкать всё ифками. Компания не хочет больше расходов на тесты и модификацию, хрупкий код и поддержку. Чтоб остаться с как можно меньшими частями специфичного клиента не плохо было бы использовать заменяемые модули, enrichment, event drive, плагины, 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. Окружение формирует архитектуру