Архитектор – это звучит… Звучит как-то не понятно. Наверное, поэтому всегда добавляют что-то. Ну типа «системный архитектор» или там «программный архитектор». Не то чтоб так стало понятно, что он делает, но точно кто-то важный. Я вообще пишу «архитектор информационных систем и программного обеспечения». Это ж как назовёшься -так и поплывешь! С архитекторами тут вообще такое дело – это как бы и не профессия. Ведь архитектором как стать? Либо тебя назовут таковым, либо сам назовёшься. Другого пути нет. Ни школы, ни спец. образования, никаких то там универсальных сертификатов нету. Только название и есть.
А раз оно есть – значит зачем-нибудь нужно! А нужно чтоб как-то указать на необходимость главного элемента мозаики – архитектуры. А раз нужен элемент, то за него, конечно, должен кто-то да отвечать. А раз должен, то вот и появляется такая должность.
Появляется, кстати, не всегда и не везде. Ведь не в каждой луже можно встретить кораблик. В самых больших - есть шанс. В такие лужи обычно и заплывают корабли из стартрека. 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.
Ну и конечно, как только нам удаётся найти и протолкнуть решение – мы идём по пути наименьшего сопротивления. Повторяющиеся паттерны во всё меньшем масштабе. Архитектура Мандельброта.
Вот где то тут я чувствую, что текста уже слишком много. Стоп. Остальные дальше просто не пройдут. Если зайдёт - буду продолжать.
Автор: Яков
