Структура и модель описания ИТ-архитектуры Gartner

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

• Бизнес-потребности, которые определяют ключевые требования к конкретной технологии для данной индустрии и организации. Фактически здесь определяется индивидуальность архитектуры. Другой важный аспект связан с позиционированием ИТ в организации – либо ИТ-архитектура формируется для максимального уменьшения издержек, либо она должна обеспечивать возможности быстрых изменений и высокую гибкость. Другие примеры могут включать быстрое распространение информации, высокую безопасность, простоту использования и требуемую степень надежности.
• Принципы, которые включают в себя те основополагающие подходы, которых придерживается руководство. Например, это может быть принцип максимального использования стандартных приложений вместо заказных разработок, правила относительно того, кто владеет данными и пр. Большинство организаций могут иметь от 20 до 30 таких базовых принципов.
• Процессы и руководства во всех областях жизненного цикла элементов архитектуры. Этот раздел может охватывать такие области как документирование требований пользователей, стили программирования, процессы обеспечения качества или управление конфигурациями устройств и систем. Здесь также могут быть определены "эталонные модели" для организации пользовательского интерфейса, доступа к данным, управления содержанием.
• Раздел Протоколы и Стандарты описывает те промышленные протоколы и стандарты, которые должны поддерживаться используемыми в организации технологиями.
• Раздел Используемые продукты и технологии является, по сути дела, утвержденным для организации списком продуктов или технологий. Они закупаются и используются как для создания приложений, так и для формирования инфраструктуры и обеспечения интеграции с внешними системами. Эта часть содержит взвешенную оценку всех "за" и "против" о конкретных поставщиках.

Таким образом, данный подход позволяет обеспечить отслеживание логической связи между выбранными технологиями, их ценностью для бизнеса и потребностями бизнеса. Эта модель в какой-то степени расширяет рассмотренные выше представления, а также подчеркивает взаимосвязь между понятиями "Электронной нервной системы" предприятия, которые были сформулированы в свое время Биллом Гейтсом, основателем, а ныне Председателем и Главным архитектором программного обеспечения компании Microsoft, и практической реализации этих идей в рамках современных подходов к проектированию архитектуры ИТ предприятия.

Билл Гейтс в своей книге "Бизнес со скоростью мысли" [5.12] дал следующее определение: "электронная нервная система есть совокупность электронных процессов, с помощью которых организации воспринимают мир и адекватно реагируют на изменения, происходящие в нем".

Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней:

• Среда бизнес-взаимодействия (Business Relationship Grid);
• Бизнес-процессы и стили бизнес-процессов;
• Шаблоны;
• Технологические строительные блоки (кирпичики – bricks).

В этой схеме верхние два уровня ориентированы на совместное обсуждение с бизнес-руководителями и ИТ-специалистами и в какой-то степени соответствуют тому, что мы называли бизнес-архитектурой, а нижние два уровня входят во внутреннюю компетенцию ИТ-службы:

• верхний уровень Среды бизнес-взаимодействия описывает новую модель "виртуального" бизнеса, а также все, что связано с кооперацией предприятий и бизнесом B2B.
• второй уровень Стили бизнес-процессов описывает, как организация выполняет свои ключевые функции, т.е. включает в себя бизнес-процессы предприятия, такие как обработка заказа, мониторинг производственных процессов, анализ использования критически важных ресурсов, совместная работа с информацией;
• следующий уровень Шаблоны описывает модели и алгоритмы, которые могут широко использоваться для решения различных задач на предприятии.
• нижний уровень Строительные блоки (Bricks) соответствует технологической архитектуре и включает в себя операционные системы, серверы, базы данных, сами данные и пр.

Этот подход является адекватным с точки зрения того, что он раскрывает руководству механизм влияния решений в области ведения бизнеса на решения в области использования ИТ на предприятии. Полная модель [5.13] представляет собой "трехмерную" комбинацию бизнес-архитектуры, технической и информационной архитектур. При этом описанные выше слои среды бизнес-взаимодействия, стилей бизнес-процессов, шаблонов и строительных блоков пересекаются со слоями Информационной архитектуры (Домен данных, Домен приложений, Домен интеграции, Домен доступа) и Технической архитектуры (Домен инфраструктуры, Домен системного управления и Домен безопасности.

Исторически архитектурная методика META Group оперировала таким понятием, как Технологическая архитектура масштаба предприятия (EWTA – Enterprisewide Technical Architecture). Однако по мере того, как в индустрии происходило понимание более тесной связи между бизнесом и информационными технологиями, в представления (домены или предметные области) архитектуры предприятия META Group были добавлены такие домены, как Бизнес-архитектура (EBA – Enterprise Business Architecture), Архитектура информации (EAI – Enterprise Information Architecture) и Портфель прикладных систем предприятия (EAP – Enterprise Application Portfolio). Это соответствует эволюции понятия "Архитектура предприятия", которая происходила на рынке в целом (см. "Архитектура предприятия: основные определения"), и принятой сегодня практике выделения доменов архитектуры.

Архитектурная методика META Group рассматривает архитектуру предприятия в интеграции с другими ключевыми процессами, в частности, с процессом управления корпоративными ИТ-программами и проектами (EPM – Enterprise Program Management) и процессом выработки стратегии и планирования. В частности, отмечается, что архитектура, собственно говоря, и реализуется на практике через процесс управления ИТ-программами и проектами.

Объединяющим для всех доменов архитектуры META Group является процесс формулировки бизнес-требований к ИТ-архитектуре, что оформляется в виде двух документов: Видения общих требований (CRV – Common requirements Vision) и Принципах концептуальной архитектуры (CA – Conceptual Architecture).

На этапе 1 разрабатывается Видение общих требований. Разработка Видения общих требований включает в себя:

• анализ тенденций развития внешней для предприятия среды, включая технологические тенденции;
• бизнес-стратегии и основные движущие силы с точки зрения бизнеса;
• требования к информационным системам со стороны бизнеса;
• требования к технологической архитектуре, которая обеспечивает адекватные возможности для информационных систем с точки зрения потребностей бизнеса.

Этап 2 состоит в разработке Концептуальной архитектуры, которая определяет логически связанный набор принципов, обеспечивающий общее руководство для развития информационных систем предприятия и технологической инфраструктуры. На этом же этапе параллельно ведется разработка наиболее приоритетных доменов архитектуры. Здесь же выполняется анализ на несоответствие (gap-анализ) между текущим и желаемым состоянием архитектуры.

Этап 3 состоит в разработке плана реализации, обеспечивающего миграцию в сторону желаемого состояния архитектуры.

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

Таким образом, результатом первого этапа работ могут быть четыре документа:

• список ключевых технологических тенденций;
• список бизнес-стратегий;
• список требований к информационным системам;
• список требований к технологической архитектуре.

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

в соответствии с методикой META Group результатом разработки принципов концептуальной архитектуры является выделение в технологической архитектуре (EWTA) набора доменов (предметных областей), которые объединяют группы связанных между собой технологий и компонент. При этом, как отмечалось в "Технологическая архитектура, стандарты и шаблоны", можно выделить два различных типа доменов технологической архитектуры: базовые (технологии, которые используются практически каждой информационной системой: сети, аппаратное обеспечение, операционные системы, системы хранения, программное обеспечение промежуточного слоя, системы управления базами данных, технологии системного управления ИТ-ресурсами в распределенной среде, архитектура безопасности) и прикладные (более специфические с точки зрения использования бизнесом технологии: системы коллективной работы, электронной почты и управления потоками работ (workflow), Интранет, Интернет-приложения, системы электронной коммерции, архитектура хранилищ данных, специализированное аппаратное обеспечение).

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

• Формулировка миссии домена: стратегические цели домена.
• Описание компонентов домена: это обеспечивает общее понимание включенных в домен технологий.
• Принципы проектирования, принятые в домене.
• Стандарты: продукты и технические стандарты, которые обеспечивают требования к технологической архитектуре.

·  Лучшие практики.

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

·  Несоответствия между существующим состоянием домена технологической архитектуры и желаемым состоянием. Это служит основой для последующих работ группы, которая отвечает за данный домен архитектуры.

При этом архитектурные домены, шаблоны и сервисы обеспечивают наращивание уровней адаптируемости технологий предприятия:

• Домены архитектуры – первый уровень адаптируемости технологий. Категоризация помогает предприятиям обнаруживать излишние технологии, продукты и конфигурации, а также позволяет идентифицировать возможности многократного использования элементов технологической архитектуры.
• Шаблоны – второй уровень адаптируемости технологий. Позволяют разработчикам использовать одни и те же конфигурации технологий для решения похожих задач.
• Сервисы – третий уровень адаптируемости технологий. Они обеспечивают общие интерфейсы для разработчиков прикладных систем и интеграторов приложений в рамках всей инфраструктуры предприятия.

При этом выделяется четыре группы сервисов по мере повышения уровня абстракции:

• Базовые инфраструктурные сервисы: общие, стандартные технологии, широко используемые в рамках всех ИТ-систем предприятия. Они ориентированы не на разработчиков прикладных систем, а на специалистов по инфраструктуре. Примерами являются ПО пересылки сообщений промежуточного слоя, мониторы транзакций, сервисы каталогов.
• Общие (framework) инфраструктурные сервисы: общие, совместно используемые технологии, которые не содержат готовой бизнес-логики (хотя она и может быть запрограммирована), ориентированы на разработчиков и могут быть не полностью стандартизированы. Примерами таких сервисов являются управление контентом, серверы приложений, серверы выполнения бизнес-правил.
• Общие (framework) бизнес-сервисы: могут быть использованы в рамках различных бизнес-процессов, поскольку они содержат готовую, предопределенную бизнес-логику. Примерами таких сервисов являются модули определения цены товара, модули персонализации информации, модули оценки кредитного рейтинга.
• Прикладные бизнес-сервисы: специфические для отдельных бизнес-процессов, содержат высокоуровневую бизнес-логику. Например, сервисы CRM-систем или систем управления поставками.

В полном описании методики META Group приводятся также следующие аспекты:

• практическая реализация архитектуры через процесс управления корпоративными ИТ-программами и проектами;
• вопросы управления и контроля архитектурного процесса (governance);
• оценка зрелости архитектуры;
• анализ технологических тенденций и планирование;
• управление портфелем ИТ-активов и проектов.

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

Основным полем для применения TOGAF является, прежде всего, программная инфраструктура информационной системы (в противоположность таким типам архитектур, как бизнес-архитектура, архитектура данных и приложений). Таким образом, она в наилучшей мере подходит для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса (mission-critical). Поскольку эта интеграционная архитектура сильно зависит от принимаемых решений в остальных областях, то в рамках TOGAF в необходимой степени рассматриваются и эти смежные области.

В состав модели TOGAF входят две основные компоненты – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Заметим, что в описании TOGAF добавлен специальный документ, поясняющий соответствие между понятиями TOGAF и моделью Захмана.

Общая структура TOGAF [5.17] показана на рис. 8.9.

В соответствии с методикой ADM, процесс разработки архитектуры включает следующие фазы:

• Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта.
• Фаза A: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством.
• Фаза B: разработка бизнес-архитектуры предприятия.
• Фаза C: разработка архитектуры данных и архитектуры приложений.
• Фаза D: разработка технологической архитектуры.
• Фаза E: проверка возможности реализации предложенных решений.
• Фаза F: планирование перехода к новой системе.
• Фаза G: формирование системы управления преобразованиями.
• Фаза H: управление изменением архитектуры.

Каждая фаза, в свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее.

Для каждого такого подпроцесса определяются решаемые в его ходе задачи, входные и выходные документы. Важно отметить, что процесс предусматривает не обязательную, но возможную адаптацию самого метода к условиям конкретного предприятия, которая осуществляется на предварительной фазе. Процесс разработки не заканчивается после выбора оптимальной архитектуры и разработки плана миграции. Необходимыми элементами являются задачи, выполняемые на фазах G и H. В частности, для обеспечения практического принятия архитектуры в организации и успеха проекта обязательным является формирование Системы управления реализацией архитектуры (Implementation Governance).

Базовая Архитектура, в свою очередь, включает:

• набор наиболее общих служб и функций, объединенных в Техническую Эталонную Модель (Technical reference model – TRM);
• набор элементарных архитектурных элементов, которые используются как "строительные блоки" при построении конкретных решений;
• база данных стандартов (Standards Information Base).

В этом смысле компонента Базовой Архитектуры, содержащая набор служб и стандартов, является некоторой абстрактной реализацией ИТ-системы в целом. Архитектура Общих Систем реализуется путем выбора и интеграции определенных служб для формирования выделенных блоков, которые могут (возможно, повторно или в различных комбинациях) использоваться в различных функциональных областях, таких как архитектура безопасности, сетевая архитектура и т.п.

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

Майкрософт. Подходы в большей степени сфокусированы на процессах разработки конкретных программных прикладных систем и создании технологической инфраструктуры, включая центры обработки данных различного масштаба и уровня надежности. Как практически и во всех других методиках, здесь выделяются четыре представления (домена) в архитектуре: бизнес-архитектура, архитектура информации, прикладные системы и технологическая архитектура. Эти представления рассматриваются на различных уровнях абстракции: концептуальном, логическом и физическом. Помимо этого, явно выделяются процессы разработки прикладных систем, организация процессов эксплуатации технологической инфраструктуры и создание соответствующих шаблонов, которые могут использоваться как при разработке архитектуры систем, так и при ее создании.

При этом компания Microsoft выработала достаточно подробные методики, покрывающие различные аспекты архитектуры и, прежде всего, процессы разработки систем и создания инфраструктуры и процессы эксплуатации систем и инфраструктуры. В частности, это такие методики, как Microsoft Solutions Framework (MSF), Microsoft Operations Framework (MOF), Microsoft Systems Architecture (MSA) и Microsoft Solutions for Management (MSM), которые мы рассмотрим ниже.

Эти четыре взаимодополняющие методики Microsoft дают специалистам рекомендации, касающиеся следующих четырех основных вопросов:

• MSF – "Как правильно создавать ИТ-системы?"
• MSA – "Как правильно создавать технологическую инфраструктуру?"
• MOF – "Как правильно эксплуатировать технологическую инфраструктуру?"
• MSM – "Как правильно строить процессы управления технологической инфраструктурой?"

Заметим, что методики Microsoft сосредоточены, в основном, на системном уровне – уровне архитектуры прикладных систем и обеспечивающей инфраструктуры (это не методики описания архитектуры предприятия в широком смысле этого слова, как мы трактуем его в курсе). Поэтому в этой более "узкой" области полезными являются приведенные соотношения между различными перспективами описания системы и моделями, используемыми для описания на соответствующем уровне абстракции. В идеале для каждой перспективы используется какой-то один тип моделей так, как это показано на рисунке. Но в реальности могут использоваться и несколько различных моделей для описания каждой из перспектив, т.е. концептуальной, логической и физической архитектур системы.

Microsoft выделяет два типа руководств и обеспечивающих методик. Первый тип руководств – это архитектурные концепции, такие, например, как сервис-ориентированные подходы к проектированию архитектуры. Эти концепции обеспечивают следующее:

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

Второй набор руководств, которыми могут пользоваться системные архитекторы – это архитектурные шаблоны, о которых уже шла речь в лекциях 5-7 и которые основаны на практическом опыте большого количества успешно реализованных проектов создания распределенных прикладных систем; они явились следствием использования описанных выше архитектурных концепций.

Корпорация Microsoft при построении любых информационных систем (не только с использованием архитектур, платформ и продуктов Microsoft) рекомендует применять методику разработки приложений, получившую название Microsoft Solutions Framework (MSF). Одно из важных достоинств методологии MSF, которая во многом опирается на представления о современной программной архитектуре, состоит в том, что в результате следования дисциплине, принципам и методам, заложенным в ее основу, решения получаются комплексными, интеграционными, работоспособными, с ясно определенными приоритетами.

MSF содержит руководства по планированию, разработке, тестированию и внедрению решений.

Компонентами MSF являются:

• Базовые принципы. Они служат основой MSF и выражают основные ценности и стандарты, применимые ко всем элементам методики.
• Модели MSF. Это в какой-то степени карты организации проектных групп и процессов работы. Две модели являются основными в методике MSF: Модель команд и Модель процессов.
• Дисциплины MSF. Это предметные области, которые используют специфический набор методов, терминов и подходов. В настоящий момент MSF включает в себя три дисциплины: управление рисками (risk management), управление подготовкой (readiness management) и управление проектами (project management).
• Проверенные практические методики (практики) MSF. Они являются плодотворными не только в сфере информационных технологий, но также и в широком спектре других отраслей. Зачастую эти методики применимы к использованию и сопровождению ИТ-систем и иных бизнес-процессов в той же степени, что и к разработке ИТ-проектов. Примерами таких практик являются анализ результатов после контрольной точки, определение и контроль факторов риска и т.д.
• Рекомендации MSF. Это не обязательные, но рекомендуемые практики и руководства, связанные с применением моделей и дисциплин MSF.

Методика Microsoft Systems Architecture (MSA) относится к той части архитектуры предприятия, которая называется Технологической архитектурой. Задачей методики является стандартизация подходов к строительству центров обработки данных (Data Centers), которые лежат в основе любой корпоративной информационной системы. Методика MSA призвана помочь ИТ-подразделениям предприятий создать такие решения, которые отвечали бы шести основным требованиям: безопасности, надежности, доступности, быстродействию, управляемости и простоте технической поддержки. Разумеется, масштабы вновь создаваемых центров обработки данных зависят, в первую очередь, от спектра возлагаемых на них задач.

MSA описывает следующие конфигурации инфраструктуры:

• Вычислительный центр уровня подразделения (DDC – Departmental Data Center).
• Вычислительный центр уровня предприятия (EDC – Enterprise Data Center).
• Вычислительный центр Интернет-систем (IDC – Internet Data Center).
• Вычислительный центр для высокомасштабируемых сервисов (HSSDS – Highly Scalable Services Data Center).

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

Date: 2015-09-05; view: 4940; Нарушение авторских прав