Относительно давно посетил семинар посвященный управлению архитектурой и ее контролю и все хотел описать полученные знания, так как информации было много, и большая ее часть была весьма полезна. Могу сказать, что представления мои об архитектуре сильно расширились, и тема оказалась более глубокой и широкой, нежели я себе ее представлял. Но это и хорошо, есть отправные точки, которые можно будет самостоятельно проработать в будущем. Итак, заканчивая с лирикой, хочу предоставить краткий конспект по архитектуре.
Большинство разработчиков, скорее всего, представляют себе архитектуру только в приложении к конкретному проекту, т.е. можно часто услышать от них «архитектура ПО», однако это лишь малая часть того, что входит в общее понятие. Условно можно разделить глобальное понятие на несколько частей, от общего к частному. Можете представить их в виде пирамиды:
- Бизнес архитектура
- Архитектура информационных систем (потоки данных)
- Технологическая архитектура
Таким образом, разработчики чаще всего говорят о технологической архитектуре приложения.
Бизнес архитектура, она же 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.
Автор: VioletTape
