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

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

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

Любые совпадения случайны, автор и в мыслях не хотел кого-то задеть или обидеть.

Приятного чтения!

Всем привет! Проведенный отпуск дал какую-то легкость мысли, и мне захотелось написать простую и немного забавную статью, в которой я бы смог на обычных примерах из своей жизни объяснить различные термины из мира ИТ архитектуры.

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

Другой мотивацией создания статьи является факт, что сейчас не существует единого общепризнанного определения термина «архитектурное мышление», поэтому куда проще описать его на примере, чем приводить кучу ссылок на разные источники. И, наконец, когда твое личное хобби и работа так гармонично сочетаются, об этом стоит рассказать!

Многие считают, что задача архитекторов – создавать схемы и диаграммы, а в широких массах эта деятельность вообще носит неофициальное название «рисовать квадратики». В какой-то степени это правда, и часть времени архитектор тратит именно на это. Ведь основным результатом работы архитектора является документ, а не часть кода или готовый программный модуль, как у разработчика, или настроенное оборудование, как у инженера. В ряде случаев отношение к этому «рисованию квадратиков» снисходительное, но ведь на практике очень часто то, что нарисовано в них, потом будет реализовано в жизни.

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