Многие считают, что задача архитекторов — создавать схемы и диаграммы, а среди широкой публики это занятие вообще носит неофициальное название «рисование квадратов».
В какой-то степени это правда, и архитектор тратит на это часть своего времени.
Ведь главный результат работы архитектора – это документ, а не кусок кода или готовый программный модуль, как у разработчика, или настроенное оборудование, как у инженера.
В некоторых случаях отношение к этому «рисунку квадратов» снисходительное, но на практике очень часто то, что в них нарисовано, потом реализуется в жизни.
Поэтому, несмотря на такую снисходительность, к созданным схемам нужно относиться со всей ответственностью.
В связи с этим логично задуматься, как правильно создавать архитектурные артефакты: документы с описаниями, схемы, модели? Как вы можете гарантировать, что архитектурная документация будет максимально полезной и будет использована другими техническими специалистами проекта? Как избежать ошибок? Есть ли уже описанные процессы, специальные инструменты и просто рекомендации? Если проект сложный и в нем участвуют несколько архитекторов в разных ролях (например, от инфраструктурных, от прикладных модулей и корпоративных), то как правильно распределить обязанности, кто что делает и в каком формате? 
Даём определение и проводим аналогии
Здесь на первый план выходят архитектурные методы.Что это? Метод представляет собой руководство по созданию и внедрению архитектурных и ИТ-решений проверенным и последовательным образом.
По сути, данное руководство представляет собой сборник знаний и опыта ведущих специалистов организации.
Методы охватывают полный жизненный цикл создания архитектуры и продуктов и включают материалы для проектирования, планирования и внедрения ИТ-решений.
Метод можно сравнить с пособием для ученика, в котором описано, что нужно сделать, кем и когда и что в конечном итоге произойдет. Или, упрощенно, метод можно представить как руководство пользователя по использованию какой-либо технологии – в общем, можно обойтись и разобраться самому, но зачем, если все уже написано.
Фреймворк и метод – в чем разница?
Здесь стоит сделать небольшое отступление и напомнить о существовании архитектурных каркасов.Какая разница, это одно и то же, скажете вы.
Не совсем: архитектурный фреймворк описывает все необходимое, а именно список ролей, артефактов, их паттернов, описание процессов и практик создания архитектуры, но архитектурный метод связывает все это воедино.
То есть фреймворк можно рассматривать как нечто статичное, а метод — как динамический.
Один фреймворк легко может быть связан с несколькими методами, но, наоборот, связь (один метод — несколько фреймворков) не совсем эффективна.
Логично иметь одну единую классификацию ролей, единый список архитектурных артефактов или практик, а не пять разных.
Гораздо разумнее иметь пять разных способов их использования или методов.
Конечно, метод может использовать не все роли и не все артефакты платформы.
В IBM, например, есть единый фреймворк с созвучным названием Unified Method Framework, который содержит исчерпывающий список практик, артефактов, ролей и с которым связаны почти все используемые методы.
Среди открытых стандартов можно привести пример Структура архитектуры открытых групп (TOGAF) И Метод разработки архитектуры (ADM) в области управления и создания корпоративной архитектуры.
Компоненты метода
Давайте подробнее рассмотрим, что включает в себя описание метода, из каких частей оно состоит? Во-первых, каждый метод должен быть однозначно идентифицирован по имени (например, «Краткое руководство по архитектуре», «Agile с дисциплиной»).Казалось бы, это весьма очевидная идея, но на практике она часто выручает, когда международная команда архитекторов (тоже из разных стран) обсуждает основные этапы предстоящего проекта.
Достаточно сказать несколько слов из названия метода, и все поймут, о чем речь, поскольку методы одинаковы для всей компании.
В целом, важность имени не следует недооценивать.
Идем дальше: метод должен включать описание процесса создания архитектуры решения и ключевых действий.
Можно сказать, что метод дает последовательные инструкции: сделай один раз, сделай два, сделай три.
Все этапы процесса связаны с ролями, описанными в структуре.
Роль может быть архитектором приложений, менеджером проекта, тренером по Agile, инженером DevOps. Этот метод также обеспечивает связь между этапами процесса и созданием необходимых рабочих продуктов.
Эти наиболее работоспособные продукты можно разделить на две категории: артефакты и результаты (результирующие продукты).
Разница очень проста: артефакты могут быть промежуточными результатами и не использоваться в качестве результата на ключевых этапах проекта.
Примером артефакта является результат собеседования при сборе требований, анализ пробелов в сравнении с эталонной архитектурой, один или несколько вариантов использования.
Кстати, упражнение по сравнению текущей архитектуры с эталонной делается практически в каждом проекте и наиболее распространёнными направлениями в последнее время являются облачный и концепция резервуар данных .
В случае результатов — это готовый прототип, описание проекта или целевая архитектура.
Как правило, для получения результата необходимо изготовить несколько артефактов.
В большинстве проектов для создания целевой архитектуры мы используем набор из около 10 ключевых артефактов, который включает в себя документы, описывающие бизнес-задачи, текущие ограничения ИТ-систем, архитектурные решения, принятые в ходе проекта, матрицу нефункциональных требований и набор моделей и диаграмм: например, компонентных, операционных и развертываний.
Этот метод также связывает рабочие продукты, сам процесс и роли участников с практикой.
Пример практики из разработки — парное программирование или разработка через тестирование, из архитектуры — практика эволюции архитектуры.
То есть метод дает описание того, какие практики лучше всего использовать при создании артефактов.
Большим блоком в описании каждого метода является часть, связанная с процессами управления.
Сюда входят такие вещи, как дорожные карты (по сути, рекомендации по использованию практик), шаблоны артефактов (матрицы требований, контрольные списки реализации, диаграммы потоков данных), а также списки и описания ключевых концепций.
Концепция — это диаграмма классов, функциональная декомпозиция, архитектурные решения — те основные понятия и вещи, которые должен знать каждый архитектор для успешной работы.
База знаний методов
Видно, что метод представляет собой описание того, как правильно создавать архитектуру, основанное на практическом опыте более опытных людей.Логично, что такие описания должны храниться централизованно в компании и быть доступны каждому.
В IBM, например, это реализовано на базе портала IBM MethodWeb, где есть список архитектурных методов и их описания.
Для повышения эффективности использования методов их можно встроить в специальные инструменты, которые архитекторы используют при проектировании решений (это давно реализовано в Rational System/Software Architect и можно сделать и в других программных продуктах.
Описание метода можно загрузить , например, в формат xml и импортировать в набор инструментов.
Методы – не только для архитекторов
В приведенных выше примерах были практики или артефакты, относящиеся не только к задачам архитекторов, но и к деятельности девелоперов.Это сделано не случайно — методы можно использовать не только в архитектуре, но и в разработке( Метод IBM Garage – метод создания облачных приложений) или даже в понимании бизнес-задач ( Дизайнерское мышление предприятия ).
Структура этих методов может незначительно отличаться друг от друга, но задача систематизации подхода остается той же.
Типы методов
Важно отметить, что вряд ли есть необходимость стремиться к единому методу разработки архитектуры.В IBM, например, существует более сотни архитектурных методов, и все они решают разные задачи.
Давайте разберемся, какие типы методов существуют: сразу их можно разделить на те, которые используются при проектировании (на этапе предпродажи) и те, которые используются при реализации решения (на этапе поставки).
Существуют методы, специально предназначенные для архитектуры приложений, инфраструктуры, данных или архитектуры предприятия.
Есть методы, специализирующиеся на Agile-разработке, другие — на водопаде.
Не так давно появились методы, ориентированные на создание продуктов на базе стека облачных технологий.
Существуют также методы, ориентированные на определенное семейство продуктов, например SAP или Oracle, которые имеют свои отличительные особенности.
Жизненный цикл метода
Стоит немного затронуть тему жизненного цикла метода.Всем известно, что технологии сейчас быстро меняются и, соответственно, нам нужно постоянно подстраиваться под этот ритм.
Казалось, еще недавно только начали использовать виртуализацию или сервисную шину, а сейчас все активно обсуждают сервисные сетки и контейнеры.
Это означает, что в компании должен быть формализованный процесс обновления и создания методов.
В IBM у каждого метода есть свой владелец, который отвечает за поддержание его актуальности для любой области деятельности компании (модернизация приложений, построение когнитивных сервисов и т. д.).
В общем, любой архитектор может предложить либо изменить текущий метод, либо создавая свой собственный.
Для этого необходимо описать его по предложенной структуре, включая все необходимые элементы, такие как роли, практики, артефакты и т. д., а также обосновать его уникальность.
Обязательным правилом добавления метода в общий реестр является его соответствие реальным практическим задачам, то есть метод должен использоваться в одном или нескольких проектах.
Что происходит в конце?
Метод представляет собой интеллектуальный капитал компании, отражающий опыт и знания ее сотрудников, основанные на результатах реализованных проектов.Благодаря этому вам не придется каждый раз в начале проекта изобретать велосипед и задаваться вопросом, с чего начать.
Эти методы увеличивают повторное использование материалов от проекта к проекту, в то же время позволяя разумно распределять задачи между участниками.
Многие консалтинговые компании используют разные методы при выполнении проектов для клиентов.
В IBM некоторые методы закрыты (Architecture Quickstart), некоторые можно лицензировать и использовать (Team Solution Design), а некоторые открыты ( Метод IBM Garage ).
С другой стороны, следует отметить, что архитектурный метод – это не панацея, которая сразу решит все ИТ-проблемы, например, связанные с бесперебойной работой продуктивных систем.
Также нелогично целиком и полностью следовать методу, когда есть небольшая задача, которую нужно реализовать в сжатые сроки, чтобы проверить какую-либо гипотезу.
Все-таки в проекте конечная цель – не использование метода, а достижение результата, например – созданного продукта.
На практике методы редко используются на 100%, и опытные архитекторы комбинируют части разных методов, адаптируя их к целям проекта, тем самым формируя свои собственные.
Но все же методы позволяют снизить количество ошибок, которые могут допустить специалисты при проектировании решений либо по неопытности, либо из-за разного понимания одних и тех же терминов и понятий, либо из-за нехватки времени.
Для крупной компании создание комплекса архитектурных методов — важная задача, позволяющая аккумулировать, систематизировать и повторно использовать практические знания, превращая их в интеллектуальный капитал.
Теги: #ИТ-компании #ИТ-компании #архитектура #Анализ и проектирование систем #архитектура системы #ibm #архитектор #ИТ-компания #создание приложений #методы #ИТ-архитектура #вендоры
-
Память И Манипуляции С Ней
19 Oct, 24 -
Подкаст Unclesoky - Эпизод №32
19 Oct, 24 -
Like.com: Поиск По Фото
19 Oct, 24
