Забота о чистоте в архитектуре

Некоторые правила, чтобы сделать ИТ архитектуру ясной и проект здоровым. Не для архитекторов, а для менеджеров.

  1. Поддерживайте баланс между временем и скоупом на проекте, сначала сокращайте скоуп.
  2. Используйте ясную терминологию.
  3. Используйте широкодоступные технологии когда возможно.
  4. Поддерживайте баланс экспертизы в команде.
  5. Запускайте технологические проекты для расширения возможностей.
  6. Повторяйте опыт несколько раз перед обобщением.

Пойдём глубже.

Поддержание баланса между временем и скоупом проекта

В сущности, Вы должны:

  1. Определить бизнес-ценность или техническую возможность, которая будет поставлена — цель проекта.
  2. Разделить проект на меньшие части (исследование, получение технической возможности, поставка функциональности).

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

Почему поддержание разумного охвата (каждого подпроекта) столь важно:

  1. Что-либо проще понять новому члену команды. Это означает, что экспертиза масштабируема и, в конечном счёте, это влияет на архитектуру.
  2. Проще коммуницировать из-за размера команды. Это ведёт к более эффективному архитектурному процессу.
  3. Когда всё прекрасно известно и цель проекта находится в поле зрения, проще находить правильные компромиссы. Участники уверены в том, на что влияет компромисс.

В любой непонятной ситуации сокращайте охват проекта (берегите время).

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

Использование ясной терминологии

Все участники проекта (Вы, техническая команда, люди из бизнеса) должны одинаково понимать одни и те же бизнес концепции. Это понятно почему, но часто недооценивается.

Основная идея столь популярной книги о Domain-Driven Design в том, чтобы разделить большой архитектурный охват на ограниченные контексты, внутри которых люди пользуются однозначным (одинаково понимаемым) языком. Таким образом, язык и охват связаны — чтобы управлять обоими вещами, Вы должны сбалансировать охват, но так же работать над словарём.

Если практический общий словарь недостижим, это обычно означает:

  1. Слишком большой охват.
  2. Нет желания думать у участников проекта.
  3. Неуважение и некомпетентность прикрываемые экономией времени.

Я рекомендую прочтение части 1 (хотя бы) книги "Domain-Driven Design: Tackling Complexity in the Heart of Software" Эрика Эванса (ISBN-13: 978-0321125217, ISBN-10: 0321125215).

Использование широкодоступных технологий

С любым ИТ проектом, Вы управляете неизвестностью и блокерами. Зачем добавлять их в форме неотвеченных вопросов о непопулярной технологии? Вы можете быть вынуждены делать компромиссы, которые Вы в нормальной ситуации делать не должны были бы, ломая архитектуру, так зачем?

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

  1. ИТ менеджер всё ещё эксперт и полагается на его / её экспертизу в маргинальной технологии.
  2. Некий не-ИТ менеджер убеждён некоторым поставщиком.

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

Поддержание баланса экспертизы в команде

Если применяется SCRUM, наличие универсальных членов команды (без фиксированных ролей) и непрерывное обучение друг у друга внутри команды это ключевая часть методологии. Это обеспечивает баланс экспертизы.

Но, если вы имеете выделенные роли, не важно по какой причине (сложный проект, культура), Вы должны подумать о разных уровнях (senior, middle, junior) внутри каждой роли.

Я имею ввиду, для каждой роли (аналитик, архитектор, разработчик, QA-инженер, DevOps-инженер и т.д.) в природе могут быть:

  • ведущий - человек ответственный за финальные решения (должен обладать высокой экспертизой по определению).
  • синьоры - люди с высокой экспертизой. Лучше использовать их для трудных задач.
  • мидлы - люди, выполняющие 40-90% обычной работы.
  • джуниоры - люди, недавно начавшие свой путь в профессии. Они экономят деньги, выполняя простые задачи (20%-70% работы).

В здоровой команде должна быть умеренная ротация и непрерывный рост от джуниоров к синьорам. Это гарантирует мотивацию, постоянное внимание к проблемам и передачу экспертизы.

Что ещё более важно, роль начинается с лида. Если Вы поняли, что нужна выделенная роль, но некого поставить ведущим из своей команды, возьмите хорошего синьора на стороне. Если поставите джуниора на ведущую позицию будет вот что:

  1. Он / она будет расти в 2-3 раза медленнее, чем мог / могла бы с хорошим лидом.
  2. Он / она может начать блокировать всё, в чём не разобрался / разобралась и ревностно переживать если кто-то углубляется в его / её сферу. Защитное поведение объясняется высокой возложенной ответственностью и неуверенностью.

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

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

Технологические проекты (исследования, переходы на новые технологии и т.п.) необходимы:

  1. Чтобы выстроить технологические возможности как таковые.
  2. Чтобы приобрести современные архитектурные практики.
  3. Чтобы поддержать баланс экспертизы в команде.
  4. Чтобы держать людей заряженными и отдающимися работе.

Вот почему вы не будете растущей компанией без технологических проектов.

Понимая вышесказанное, не надо формально "выжимать результат" из технологических проектов, ориентируясь только на 1-ю цель. Без обучения, ошибок и их исправления (оставьте время на это), нет хорошей архитектуры и, значит, нет будующего у той технологической возможности, которую вы создаёте.

Повторение опыта перед обобщением

Слишком раннее обобщение есть форма овер-инжиниринга (заумства).

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

Второе, модуляризуйте решение и избегайте тесного связывания.