1 задание. Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое
 Скачать 8 Mb.
|
|
Критерии выбора методологии Так как методологии сильно отличаются друг от друга, то следует задать критерии для их сравнения. Полнота таксономии, определяет, насколько методология пригодна для классификации различных архитектурных артефактов. Полностью сосредоточена на фреймворке Захмана. Полнота процесса, определяет, насколько детально представлен процесс создания архитектуры предприятия. Руководство по эталонным моделям, определяет полезность методологии в создании адекватного набора эталонных моделей. На этом практически полностью сосредоточена методология FEA. Практическое руководство определяет, насколько методология позволяет воплотить в жизнь умозрительное представление об архитектуре предприятия и сформировать культуру, в которой эта архитектура будет использоваться. На этом практически полностью сосредоточена методология Gartner. Модель готовности определяет, насколько методология позволяет оценить эффективность использования архитектуры предприятия в различных подразделениях. Ориентированность на бизнес определяет, ориентирована ли методология на использование технологии для повышения ценности бизнеса, где ценность бизнеса определяется как снижение затрат или увеличение доходов. Руководство по управлению определяет, насколько методология полезна в понимании и создании эффективной модели управления для архитектуры предприятия. Руководство по разбиению определяет полезность методологии в эффективном разбиении предприятия на отделы, что весьма важно при управлении сложностью. Наличие каталога определяет, насколько эффективно методология позволяет создать каталог архитектурных активов, которые можно будет использовать в дальнейшем. Нейтральность по отношению к поставщикам услуг определяет вероятность того, что при внедрении методологии вы окажетесь привязанными к конкретной консалтинговой организации. Высокая оценка означает низкую степень привязки к конкретной организации. Доступность информации определяет количество и качество бесплатных или относительно недорогих материалов по данной методологии. Время окупаемости инвестиций определяет продолжительность периода, в течение которого вы будете использовать данную методологию, прежде чем сможете построить на ее основе решения, обеспечивающие высокую ценность бизнеса. Построение Архитектуры Предприятия может быть выполнено с применением различных методов и практик. В данной книге мы вкратце рассмотрим несколько и сфокусируем свое внимание на одной из них: •«Zahman Framework» – наиболее ранняя и известная методология. Идеально подходит для «классификации» элементов архитектуры. •«TOGAF (The Open Group Architecture Framework)» . Методология получила широкую известность и распространение, во многом за счет открытости. Представляет из себя каркас «построения процессов». •«Gartner» – методология экспертного анализа с использованием «лучших» практик. •«FEAF» – методология построения архитектуры, использующая «сервис ориентированный» подход. При построении ИТ Архитектуры Предприятия необходимо выделить следующие состояния архитектуры организации: •Текущее состояние «As-is» или «Baseline Architecture». •Переходное состояние «Transition Architecture». •Будущее состояние «To-be» или «Target Architecture». •План перехода «Enterprise Architecture Management Plan & Roadmap» В общем случае Архитектура Предприятия представляет из себя план перехода от «Текущего» к «Будущему» состоянию организации. Архитектурный проект длится несколько лет и инициирует множество ИТ проектов. Эти проекты будут разной продолжительности, у них разные даты начала и окончания. Их нужно сгруппировать таким образом, чтобы изменения в бизнесе и ИТ происходили в нужное время, с минимальными рисками и без проблем с совместимостью. То есть архитектура может переходить из одного работоспособного состояния в другое несколько раз за время архитектурного проекта. Промежуточное состояния называют «переходной архитектурой» (Transition Architecture). Архитектура Предприятия на основе методологии «ZAHMAN FRAMEWORKS» Наиболее ранняя методология и на мой взгляд наиболее полная и структурированная. Изначально разрабатывалась как архитектура Информационных Систем. Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Модель «Захмана» используется для описания предприятия в целом, так что предложенная модель, вообще говоря, может использоваться как средство для описания архитектур сложных производственных систем любого типа. Основные характеристики данной модели: •целостность в отношении предприятия; •обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий; •применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия предприятия как целого; •простота описания Модель Захмана имеет такие преимущества перед другими моделями: •Отличается своей простотой понимания как техническими, так и нетехническими специалистами. •Более детальными описаниями компонентов архитектуры •Возможность применения для планирования, позволяющего лучше принимать решения. •Наиболее наглядным представлением компонентов компании. •Описанием сложной архитектуры небольшим количеством нетехнических понятий. •Независимостью конкретных инструментов описания. •Может использоваться как средство для описания архитектур сложных производственных систем любого типа. Архитектура Предприятия – матрица «Zahman Framework» Архитектура Предприятия на основе методологии «FEAF» FEAF- фреймворк разработанный правительством США, как некий подход для развития информационных технологий правительственных учреждений, приведенный к использованию единой архитектуры. В основе FEAF лежат пять эталонных моделей: •Исполнительная модель. •Бизнес-модель. •Сервисная модель Компонента. •Техническая эталонная модель. •Эталонная модель данных. Одно из полезных свойств фреймворка FEA – принцип сегментного подхода, дает возможность ускорить внедрение «Архитектуры предприятия». Процесс разработки архитектуры предприятия по методологии FEA включает в себя следующие этапы: •Анализ Архитектуры •Архитектурное определение •Стратегия инвестиций и финансирования •План управления программой и реализация проекта Архитектура Предприятия на основе методологии «GARTNER» Методология Gartner – эту модель можно описать как набор рекомендаций по созданию архитектуры предприятия. Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней: •Среда бизнес-взаимодействия (Business Relationship Grid); •Бизнес-процессы и стили бизнес-процессов; •Шаблоны; •Технологические строительные блоки (кирпичики – bricks). Методология Gartner – по сути своей не является методологией, как например структурированная модель Захмана, ни процессом как TOGAF, ни как FEA. Gartner – является набором практических рекомендаций. Данная методология является сборником советов по построению архитектуры предприятия от одной из наиболее известных в мире консалтинговых ИТ-компаний – Gartner. Данный фреймворк представляет собой трехмерный куб, состоящий из слоев: •Горизонтальные слои. •Вертикальные домены. •Вертикальные элементы технической архитектуры. Архитектура Предприятия на основе методологии «TOGAF» Основным полем для применения TOGAF является, прежде всего, программная инфраструктура информационной системы. Она в наилучшей мере подходит для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса. Описание модели: •Обзор бизнес – архитектуры •Описание существующей системы с необходимой степенью детализации •Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре •Разработка черновика технического отчета •Направление черновика отчета на рецензирование TOGAF позиционируется не как некоторая эталонная модель, а как «средство для разработки архитектур информационных систем». Основное назначение – ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития. Рассмотрим построение Архитектуры Предприятия на основе методологии «TOGAF» более детально, который на мой взгляд имеет ряд преимуществ: •Подход TOGAF позволяет построить весь архитектурный процесс – от запуска практики до результатов. •TOGAF – это де-факто является стандартом. Имеется программа сертификации по TOGAF. •TOGAF – абсолютно бесплатен. Множество открытых ресурсов, скачивайте и используйте. •TOGAF содержит полный набор инструментов для создания и развития архитектурной практики в организации. Есть пошаговый процесс для разработки описания Архитектуры Предприятия и полный набор инструментов, шаблонов и т. д. •TOGAF совместим с другими Фреймворками, например, с «Zahman Framework». Как архитектурный процесс модель TOGAF дополняет модель Захмана – которая, классифицируется как архитектурная таксономия. Захман показывает, как следует классифицировать артефакты. Модель TOGAF описывает процесс создания артефактов. Структура Архитектуры Предприятия «TOGAF» Методология TOGAF и инфраструктура Захмана хоть и объединены к категории «инфраструктур предприятия», но имеют отличия в своих принципах, структурах и компетенциях. TOGAF- представляет собой функциональную и динамичную инфраструктуру, которая включает руководящие принципы моделей процесса их использования. В то время как фреймворк Захмана представляет собой статичную структуру архитектуры, наиболее эффективна для применения анализа и метаанализа фреймворков инфраструктур. Несмотря на значительные отличия данных фреймворков их можно использовать совместно. Базовые принципы Процесс создания конкретной архитектуры предприятия рассматривается как переход от общей архитектуры к специализированной. Методика разработки архитектуры в модели TOGAF представляет собой процесс осуществления такого перехода. В модели TOGAF наиболее обобщенные архитектуры называются фундаментальными архитектурами. Эти принципы построения архитектуры теоретически могут использоваться практически любой ИТ-организацией в мире. Следующий уровень специализации в модели TOGAF называется общесистемными архитектурами. Эти принципы прослеживаются во многих – возможно, не во всех – типах предприятий. Далее идет отраслевой уровень архитектурой. Эти принципы характерны для предприятий, занятых в одной сфере деятельности. И наконец финальный уровень – это уровень архитектуры организации. Это самый высокий уровень специализации в модели TOGAF. Это архитектуры конкретных предприятий. В состав модели TOGAF входят две основные компоненты: •методика ADM (Architecture Development Method) , определяющая процесс разработки архитектуры. •Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Описание TOGAF включает в себя 7 частей: •Introduction. Cодержит высокоуровневое описание ключевых концепций Архитектуры в целом и TOGAF в частности. •Architecture Development Method (ADM) . Ключевая часть TOGAF, описывает пошаговую методику разработки Архитектуры Предприятия. •ADM Guidelines and Techniques . Включает в себя описание правил и техник, которые используются в TOGAF ADM. •Architecture Content Framework . Описывает подход к описанию Архитектуры Предприятия. Содержит метамодель архитектурных артефактов, структуру и описание типовых архитектурных артефактов. •Enterprise Continuum & Tools . Описан подход к категоризации и хранению результатов архитектурных активностей. •TOGAF Reference Models . Описание эталонных моделей, которые вы можете использовать в ваших проектах. •Architecture Capability Framework. Подход к организации архитектурной практики в компании. Структура, процессы, роли, навыки и полномочия, требуемые для работы архитектурной практики в компании. В качестве основных процессов построения Архитектуры Предприятия важно внедрить всего четыре ключевых процесса: •Создания и развития Архитектуры Предприятия. •Управления изменениями. •Контроль реализации архитектурных решений. •Управления практикой. Метод Развития Архитектуры (Architecture Development Method ADM) TOGAF В TOGAF процессы создания и развития, управления изменениями, контроля реализации архитектурных решений интегрированы в единый архитектурный цикл Метод Развития Архитектуры (Architecture Development Method ADM). Данный метод можно и нужно адаптировать под задачи вашей компании на всех уровнях разработки архитектуры. При этом, нет необходимости делать все возможные документы. Не нужно погружаться во все детали. На каждом этапе ADM предлагает готовый набор техник, инструментов, шаблонов и чек листов. Метод Развития Архитектуры (ADM) содержит десять фаз. Каждая фаза, в свою очередь разбивается на под-процессы (этапы), отдельные работы и так далее. Например, фаза D включает следующие основные под-процессы: •Описание существующей технологической архитектуры. °Обзор бизнес-архитектуры, архитектуры данных и приложений для определения начальных данных и необходимой степени детализации. °Описание существующей системы с необходимой степенью детализации, которая выбирается для того, чтобы можно было выявить необходимые изменения при формировании целевой архитектуры. Формирование реестра используемых платформ программного и аппаратного обеспечения. °Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах. °Разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков. °Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок. •Формирование целевой технологической архитектуры. °Описание существующей системы в терминах TOGAF. °Определение перспектив (представлений) архитектуры. °Формирование модели целевой архитектуры. °Определение ИТ-служб (сервисов). °Подтверждение учета бизнес-требований. °Определение архитектуры и используемых блоков (шаблонов). °Проведение анализа расхождений (gap analysis). Таблица: Фазы и задачи Метода Развития Архитектуры Предварительная фаза. Основные задачи: •Создать архитектурную практику, •подготовить компанию к запуску архитектурных проектов, •заручиться поддержкой руководства, •сформулировать архитектурные принципы, •адаптировать методологию под цели и задачи компании Фаза А – Видение архитектуры. Основные задачи: •Запустить архитектурный проект, определить цели и задачи, определить рамки, предположения и ограничения проекта, разработать видение архитектуры, определить всех заинтересованных лиц, •разработать «Устав проекта» и получить формальное подтверждение старта проекта. Фаза B – Бизнес Архитектура. Основные задачи: •Разработать архитектуру с описанием текущей и целевой архитектуры, •Анализ расхождений Фаза C – Архитектура Информационных Систем . Задачи: •Разработать архитектуру с описанием текущей и целевой архитектуры, •Анализ расхождений Фаза D – Техническая Архитектура. Основные задачи: •Разработать архитектуру с описанием текущей и целевой архитектуры, •Анализ расхождений Фаза Е – Возможности и решения. Основные задачи: •Выполнить начальное планирование реализации задач проекта. •Идентифицировать основные проекты внедрения и сгруппировать их в переходные архитектуры. Фаза F – Планирование миграции. Основные задачи: •Анализ затрат и рисков. •Разработка детального плана внедрения и миграции. Фаза G – Управление реализацией. Основные задачи: •Архитектурный надзор за проектами внедрения. •Подготовить архитектурные контракты. •Обеспечить соответствие архитектуре результатов проектов внедрения. Фаза H – Управление изменениями архитектуры. Задачи: •Подготовится к следующему витку жизненного цикла архитектуры. •Процесс управления изменениями должен обеспечить соответствие архитектуры актуальным потребностям бизнеса и дать максимальную ценность бизнесу. Управление требованиями. Основные задачи: •На каждой фазе архитектурного проекта собираете и согласуете бизнес требования. •Требования должны быть идентифицированы, сохранены, определены приоритеты и использованы на соответствующих фазах архитектурного проекта. Спецификация TOGAF также позволяет гибко работать с этапами. В самой спецификации говорится следующее: Перед применением методики разработки архитектуры необходимо проверить компоненты на применимость, а затем связать их с конкретными обстоятельствами отдельного предприятия. Это позволяет создать методику разработки архитектуры для конкретного предприятия. Модель TOGAF позволяет выполнять этапы частично, пропускать их, объединять, изменять порядок и вносить изменения в соответствии с конкретными требованиями. Неудивительно, что два сертифицированных консультанта по TOGAF могут разработать два совершенно различных процесса – даже при работе с одной и той же организацией. Модель TOGAF обладает еще большей гибкостью в отношении созданной архитектуры. Фактически TOGAF, как это ни удивительно, «ничего не знает» об архитектуре. Окончательная архитектура может с одинаковым успехом быть хорошей, плохой или неопределенного качества. В TOGAF описывается, как создать архитектуру предприятия, но не описывается, как создать хорошую архитектуру. Качество конечного продукта зависит от опыта персонала компании и консультанта по TOGAF. Те, кто внедряет TOGAF в надежде получить чудодейственное средство, будут жестоко разочарованы (впрочем, как и при использовании любой одной методологии). |