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