Архитектура и архитекторы

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

Большинство разработчиков, скорее всего, представляют себе архитектуру только в приложении к конкретному проекту, т.е. можно часто услышать от них «архитектура ПО», однако это лишь малая часть того, что входит в общее понятие. Условно можно разделить глобальное понятие на несколько частей, от общего к частному. Можете представить их в виде пирамиды:

  • Бизнес архитектура
  • Архитектура информационных систем (потоки данных)
  • Технологическая архитектура

Таким образом, разработчики чаще всего говорят о технологической архитектуре приложения.

Бизнес архитектура, она же Enterprise, является представлением того, как эффективно перевести цели бизнеса и стратегию путем создания, улучшения и объединения ключевых требований, принципов и моделей для успешного развития бизнеса и достижения поставленных целей. Определение взято из английской википедии.  Архитекторы уровня Enterprise должны ориентироваться на бизнес потребности и проводить анализ потоков данных, т.е. покрывают два указанных пункта. Архитекторы уровня Solution занимаются технологическими аспектами проектов. Так же стоит упомянуть не обозначенных здесь Infrastructure Architect, людей, которые занимаются глобальным развитием и анализом технических возможностей по реализации проектов.

Получается, что есть 3 вида/уровня архитекторов:

  • Enterprise (EA)
  • Solution (SA)
  • Infrastructure (IA)

В аспекте разработки, далее будем рассматривать задачи и ответственности EA и SA, не забывая впрочем, о важной роли IA.

Отличия Enterprise Architect от Solution Architect

Если совсем кратко, то:

  • Enterprise – что делать
  • Solution – как делать

К кругу вопросов и задач, которые стоят перед EA можно отнести:

  • Определение и решение об оборудовании, на котором будет работать приложение и/или его части.
  • Определение потоков данных, взаимодействие с другими информационными системами в пределах компании и за ее пределами.
  • Разработка плана разворачивания приложения, определение зависимостей.
  • Разработка плана администрирования приложения и вопросов доступа\безопасности.

Вопросы перед Solution Architect более знакомы простым разработчикам, например:

  • Выбор фреймворков для работы;
  • Представлений пользователю;
  • Контроль за развитием приложения;
  • Решение спорных моментов у разработчиков.

Различия графически можно представить следующим образом:

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

Например, в какой-то момент появляется потребность в новом приложении Х, которое использует данные, которые генерирует приложение А. В таком случае ЕА принимает решение о выделении части приложения А в отдельный сервис, который будет поставщиком данных для приложения Х. Таким образом может быть заметно сокращена работа по реализации нового приложения.

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

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

Уровни ответственности и влияния

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

Возможные артефакты enterprise architecture:

  • Проектные планы
  • Отображение бизнес-процессов на системы
  • Бизнес-процессы
  • Организационная структура
  • Технологическая архитектура интеграции систем
  • Структуры данных
  • Топология развертывания систем и их компонент
  • Топология сети и подключения оборудования
  • Физическое размещение систем
  • Реестры систем и оборудования
  • Функциональные системы

Связь между ними на фотографии ниже. Извините за качество.

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

Работа архитекторов

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

Определенных средств для разработки и контроля никто не называл. Так или иначе, используется компиляция средств из Visio, SharePoint, Wiki.

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

Из дополнительного материала можно порекомендовать TOGAF9 и блог Nick Malik.

 

Hard’n’Heavy!

 

Violet Tape

3 комментарий на “Архитектура и архитекторы

  1. Если я правильно понял…
    ЕА — это тот кто взаимодействует с Заказчиком и объясняет SA, что программа должна делать.
    SA — ставит задачи программистам и следит за их выполнением.

    Че то мне сомнительно, что стоит эти функции делить между двумя людьми. Не позволительная роскошь и увеличение затрат.

    • Немного не так. EA и SA в небольших командах разработки совмещены в отдном человеке. В больших EA строить стратегию того, как вообще будут работать приложения и рисует стратегию взаимодействия, все остальное отдается на откуп SA.
      Во время работы в Intel так все и было. Были региональные советы архитекторов, которые глобально решали/рекомендовали технологии для взаимодействия между системами, после чего сообщали группам разработки. В этих группах уже были свои архитекторы, которые принимали решения по реализации исходя из глобальных рекомендаций.
      В качестве примера можно представить основное хранилище данных, глобальное для компании и EA дают карты данных как с ними взаимодействовать, что и где можно взять, какими уже существующими сервисами воспользоваться для работы. SA далее это принимает к сведению и строит архитектуру приложения исходя из этих данных.
      В локальных группах техлид часто выступает в роли SA.
      Опять же вспоминая интел и некоторые другие компании, задачи прорабатываются соообща, после того, как важность задач утверждена заказчиком.

Оставить комментарий