Pull to refresh

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

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


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

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

Бизнес архитектура, она же 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.

UPD
Рассказчиком был Сергей Орлик и это была компиляция его предыдущих рассказов об архитектуре. Слайды доступны по адресу www.slideshare.net/sorlik/presentations
Tags:
Hubs:
+20
Comments 16
Comments Comments 16

Articles