On_load_lecture(); Стратегическая модель архитектуры SAM
Лекция 9. Архитектурные методики
NASCIO Architecture Toolkit
Набор шаблонов IT Architecture Toolkit, разработанный американской ассоциацией CIO, первоначально позиционировался как специализированное средство для документирования ИТ-архитектуры организации. Основное преимущество его использования заключается в построении иерархической системы описаний элементов, удобной для поддержания жизненного цикла документа, т.е. в форме, предполагающей его возможные изменения в будущем по мере изменения требований бизнеса и совершенствования технологий. Однако в версии 3.0, опубликованной в октябре 2004 года, предмет его рассмотрения уже охватывает и область бизнес-архитектуры, так что он может рассматриваться наряду с другими универсальными рамочными моделями. Другим весьма полезным обстоятельством является большое количество реальных примеров из практики отдельных американских штатов и федеральных организаций.
Для целей сравнительного анализа интересно проследить эволюцию данного подхода, поэтому вначале рассмотрим основные идеи, заложенные в версию 2.0. В этой версии структурная схема этой методики включала в себя пять уровней:
1. области или домены (Domains) ИТ-архитектуры;
2. дисциплины;
3. технологические дисциплины;
4. продуктовые компоненты;
5. документы соответствия.
Области (домены) являются логическими блоками технологической архитектуры. Каждая Область может включать одну и более дисциплин. Вся ИТ-архитектура подразделялась на набор областей верхнего уровня (доменов), описывающих отдельные аспекты ИТ-систем. В составе списка доменов предлагалось выделять такие области, как:
|
|
|
1. управление приложениями;
2. управление данными;
3. управление информацией;
4. интеграция;
5. управление пользователями и доступ;
6. сети и коммуникации;
7. платформы;
8. управление системами;
9. информационная безопасность и т.п.
Дисциплины обеспечивают логическое деление доменов на разделы, которыми уже проще управлять, т.е. домены включают в себя несколько функциональных дисциплин. Дисциплины представляют собой достаточно связанные единицы в рамках соответствующей предметной области. Каждая дисциплина содержит одну и более Технологических дисциплин.
Например, в домен Управление системами входят, в том числе, следующие дисциплины:
1. Управление активами (Asset management).
2. Управление изменениями (Change management).
3. Управление событиями (Event Management).
4. Поддержка пользователей (HelpDesk).
5. Обеспечение непрерывности бизнеса (Business continuity) и др.
Технологические дисциплины – это технические дисциплины, которые поддерживают функциональные технологические разделы архитектуры. В качестве примера (см. табл. 9.3 ниже) можно привести Дисциплину "Управление данными" (Data Management), которая является частью Области "Информация". Дисциплина "Управление Данными" может включать в себя такие Технологические Области, как:
|
|
|
1. реляционные СУБД;
2. плоские файловые системы;
3. настольные базы данных;
4. модели данных.
Каждая из этих технологических областей включает свои продукты, протоколы и связанные с ними конфигурации. Это детализируется на уровне "Продуктовые компоненты". С указанного уровня начинаются технические детали технологической архитектуры.
Продуктовые компоненты включают протоколы, продукты (семейства продуктов) и конфигурации, которые специфичны для каждой технологической области. Примерами Продуктовых Компонент, которые могут быть идентифицированы в рамках технологической области "Модели Данных", являются такие продукты, как ERWin, Visio и Designer 2000. Документация для каждой компоненты включает оценочные критерии, которые были использованы для включения продуктовой компоненты в общую технологическую архитектуру.
Документы Соответствия определяют руководства, стандарты и регулирующие документы, которые связаны с Дисциплинами, Технологическими дисциплинами и/или Продуктовыми компонентами. Они предписывают необходимость соблюдения тех или иных международных рекомендаций (RFC), стандартов, законодательных актов – например, по применению сертифицированных средств ЭЦП, внутренних инструкций и т.п.
|
|
|
Документы соответствия могут присутствовать на каждом из этих уровней и обеспечивают основу для принятия важных решений о новых продуктах, протоколах, конфигурациях и т.д.
Для элементов описания архитектуры в документе определяется следующее:
| Таблица 9.1. Элементы описания архитектуры | |
| Область (домен) | Описание, область охвата, входящие функциональные области, принципы, лучшие практики, тренды |
| Дисциплина | Описание, область охвата, ссылка на Домен, кросс-ссылки на другие функциональные области, методологии, Технологические Области, требования к документированию |
| Технологическая дисциплина | Описание, ссылка на функциональную область, обоснование выбора единственного или множественных продуктов (вендоров, приложений) |
| Продукты/приложения | Описание, ссылка на Технологическую область, информация о вендоре, классификация, условия использования, политика миграции |
Важным преимуществом такого подхода является возможность представления всего описания архитектуры в виде единой (гипертекстовой) базы данных, что позволяет эффективно организовать процессы управления жизненным циклом отдельных документов (см. ниже), а также эффективно разграничить права доступа к отдельным разделам (например, документам, описывающим применяемые средства защиты информации) при сохранении целостности и единства описания.
|
|
|
Пример приведен в табл. 9.2.
В таблице 9.3 дан пример модели технологической архитектуры, включающей в себя девять Областей, которые, в свою очередь, разбиты на 26 технических функциональных элементов или Дисциплин. Каждая организация должна определять свой набор технических дисциплин в зависимости от потребностей, но приведенный пример может служить отправной точкой.
В версии 3.0 набор включает в себя как процесс управления ИТ (IT Governance), так и следующие 4 взаимосвязанные архитектуры:
1. бизнес-архитектуру;
2. архитектуру информации;
3. технологическую архитектуру (практически соответствует всей ИТ-архитектуре, рассмотренной в версии 2);
4. архитектуру решений (Solution Architecture),
поэтому структура модели частично изменилась.
| Таблица 9.2. Пример иерархии описания архитектуры в соответствии с рекомендациями NASCIO | ||||
| Область (Домен) | Дисциплина | Технологическая дисциплина | Продуктовые компоненты | Документы Соответствия |
| Информация | Управление Данными |
|
|
|
|
| |||
|
|
| ||
|
|
| ||
В частности, в составе собственно бизнес-архитектуры предлагается выделить несколько бизнес-областей (доменов). Это разделение может производиться как по функциональному (например, образование /здравоохранение /социальное обеспечение), так и по некоторому "тематическому" признаку (например; услуги гражданам/взаимодействие с другими органами власти/внутренние процессы) или географическому признаку. В составе этих бизнес-доменов выделяются отдельные архитектурные компоненты, рассмотрение которых может вестись с различных "перспектив", соответствующих столбцам в модели Захмана и с фокусом на двух верхних уровнях (строках) этой модели. В руководстве указывается на возможную целесообразность объединения таких перспектив, как "Кто?" и "Зачем?", вообще говоря, различных с точки зрения модели Захмана, в одну общую – "Стратегический бизнес". Важно отметить, что одни и те же выбранные перспективы должны будут применяться ко всем бизнес-областям.
Для каждой бизнес-области в описании определяются существенные принципы, лучшие практики и существующие тенденции. Далее, в составе бизнес-области формируются подчиненные документы, описывающие ее компоненты, которые фактически соответствуют отдельным ячейкам в верхних двух уровнях модели Захмана. Таким образом, в состав компонент могут входить, например, описание ролей (должностей) и их ответственности в организации, важные с точки зрения предприятия события и циклы деятельности, расположения офисов и т.п. Важным атрибутом описания является индикация типа состояния компоненты, т.е. относится ли это описание к существующему или целевому состоянию. Здесь прослеживается некая аналогия с подходом группы Зиндера и выделением "стратегического времени", хотя и в ограниченной интерпретации из всего двух состояний.
| Таблица 9.3. Области и Дисциплины | |
| Область | Дисциплины |
| Информация |
|
| Приложения |
|
| Интеграция |
|
| Доступ |
|
| Сеть |
|
| Платформа |
|
| Системное Управление |
|
| Частная информация |
|
| Безопасность |
|
Специальным типом компоненты являет так называемая Gap-компонента,, которая описывает существующие расхождения между текущим и целевым состоянием. Эти компоненты не случайно выделены в отдельный тип, поскольку одна и та же "причина", такая, например, как используемая устаревшая технология доступа к данным, может оказывать влияние на целый ряд основных компонент, в том числе из различных функциональных или тематических бизнес-областей. Описания этих основных компонент и описания gap-компоненты дополняются соответствующими кросс-ссылками, позволяющими осуществлять необходимую навигацию.
Представленный ранее в предыдущей версии руководства в рамках общей ИТ-архитектуры домен "Информация" в новой версии выделен в отдельную архитектуру информации. В ее составе определяются следующие элементы:
1. основные информационные сущности (information subject areas), такие как, например, Гражданин/Услуга/Платеж, которые специфичны для деятельности данной организации;
2. процессы обработки информации, описывающие, в частности, каким образом, кем и в каком порядке используется, например, сущность "Гражданин";
3. метаданные, определяющие, какова логическая и физическая структуры данных, существующие или целевые бизнес-правила, уровень конфиденциальности, кто является владельцем/ответственным за качество и т.п. для данной сущности.
Кроме того, как и в случае бизнес-архитектуры, здесь явно выделяются Gap-компоненты.
Новым понятием, которое требует некоторого комментария, является архитектура решений. В данном контексте под ней понимается "процесс в рамках общей архитектуры предприятия, который фокусируется на создании сервиса или решения в интересах всей организации".
В отличие от остальных архитектур, описания элементов архитектуры решений не содержат такого признака, как "существующий" или "целевой". Фактически, все эти "решения" относятся как раз к стадии перехода от существующего состояния к целевому , так что по завершении соответствующего проекта они сохраняются со статусом "архивный".
Для описания конкретного решения используются три типа шаблонов:
1. "обзор" (scope) – определяет область проекта, цели и подход;
2. "требования" – содержит формализованные требования к решению, сгруппированные по типу, т.е. бизнес-требования, функциональные, по безопасности и т.п. В этой части организация шаблона схожа с разделом отечественного стандарта ГОСТ 34.698-90 "Техническое задание на АС";
3. "дизайн" – документирует существенные элементы предложенного решения, включая явные ссылки на соответствующие требования и другие существующие элементы бизнес-архитектуры, архитектуры информации или технологической архитектуры.
Как уже отмечалось выше, наряду с описанием элементов архитектуры, в ходе процесса разработки определяется реализация применительно к конкретным особенностям предприятия стандартных процессов поддержки жизненного цикла архитектуры. К этим процессам относятся, в частности, такие:
1. документирование;
2. рецензирование;
3. информирование;
4. изменение;
5. проверка соответствия;
6. поддержка актуальности;
7. организация и управление разработкой архитектуры, включая построение системы "IT Governance".
Диаграммы процессов строятся применительно к набору типовых предопределенных ролей (например, Рецензент, Документатор, Лидер и т.п.), которые присваиваются отдельным сотрудникам, должностям или подразделениям. Эти роли определяют права и ответственность данных участников процесса.
Модель "4+1" представления архитектуры
Достаточно важную роль в развитии подходов к описанию архитектуры предприятия сыграла модель "4+1" (точнее "The 4+1 View Model of Architecture"), которая была предложена Филиппом Кручтеном (Philippe Kruchten) из компании Rational еще в 1995 году. Данная методика позиционировалась, прежде всего, как способ описания архитектуры систем, основанных на активном использовании программного обеспечения, хотя идеи, заложенные в эту методику, могут использоваться и в более широком контексте архитектуры предприятия – что, собственно, и произошло на практике.
Рис. 9.1. Модель "4+1"
Модель предлагает простой и понятный способ описания архитектуры сложных систем, который состоит в использовании пяти различных категорий или представлений(views). Четырьмя основными представлениями в этой методике являются следующие:
1. Логическое представление. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования).
2. Процессное представление. Описывает вопросы параллельного исполнения и синхронизации процессов.
3. Физическое представление. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы.
4. Представление уровня разработки. Описывает статическую организацию программной системы в среде разработки.
Описание архитектуры системы на основе этих четырех представлений иллюстрируется и проходит проверку путем использования еще одного представления, которое содержит некоторые отобранные сценарии использования (use cases). Архитектура системы во многом определяется этими сценариями. Каждое представление отражает специфические аспекты моделируемой системы.
Основной целью логического представления в данной методике является описание функциональных требований: что система должна выполнять в терминах конечных пользователей. Для этого представления используются различные абстрактные конструкции, такие как объекты и классы объектов. Для их иллюстрирования могут применяться диаграммы классов (в нотации языка UML) либо, например, диаграммы "сущность-связь", если в разработке приложения доминируют данные.
Процессное представление учитывает некоторые нефункциональные требования к системе, включая производительность и доступность. С помощью этого представления рассматриваются такие аспекты, как одновременное выполнение и распределение процессов, интеграция системы, устойчивость к сбоям, а также то, как основные объекты абстракции, рассмотренные на уровне логического представления, соответствуют архитектуре процессов. Архитектура процессов может быть представлена на различных уровнях абстракции. На самом высоком уровне система рассматривается как набор независимо выполняемых сетей взаимодействующих между собой программ. На более низких уровнях рассматриваются процессы и задачи.
Представление уровня разработки описывает фактическую организацию модулей системы, разделение ее на подсистемы, которые могут разрабатываться независимо.
Физическое представление, в основном, рассматривает нефункциональные требования, такие как доступность, надежность, устойчивость, производительность, масштабируемость. Этот уровень описывает распределение различных элементов – сетей, процессов, задач и объектов – по различным узлам (элементам аппаратного обеспечения, объединенным в сеть).
Сценарии объединяют все представления вместе. Сценарии использования описываются как последовательность взаимодействия объектов и процессов. Они отражают наиболее важные требования, которым должна удовлетворять система. Это представление в каком-то смысле является избыточным и пересекается с четырьмя предыдущими, но оно важно по следующим причинам:
1. Сценарии использования позволяют идентифицировать элементы архитектуры, которые требуются для эффективно работающей системы.
2. С помощью сценариев можно выполнять проверку и иллюстрацию того, что архитектура является работоспособной и полной. Это также является основой для проведения тестирования архитектурного прототипа.
on_load_lecture(); Стратегическая модель архитектуры SAM
Методика Стратегическая модель архитектуры SAM (Strategic Architecture Model) является интересным инструментом анализа и документирования архитектуры предприятия и связанных с ней доменов, Эта методика активно и успешно применяется, в частности, консультантами Microsoft во внутренних и внешних проектах и помогает в создании документов, которые передаются заказчикам и партнерам в ходе работы. Сама методика была разработана английской консалтинговой компанией Systems Advisers Ltd.
SAM использует нотацию "сфер интересов" для представления целостного набора фактов о предприятии и "отношений", которые связывают эти факты в полезные группы, что обеспечивает полезный взгляд на структуру и операции, выполняемые предприятием.
SAM можно рассматривать как некоторую надстройку над моделью архитектуры предприятия Захмана. Она предоставляет общие структуры для определения архитектуры и механизмы, позволяющие организовать и анализировать информацию об архитектуре.
SAM использует итеративный подход при создании архитектуры, сочетающий элементы разработки "сверху–вниз" и "снизу–вверх". "Сферы интересов" SAM позволяют легко систематизировать всю информацию, имеющую отношение к определенному предмету, например, информацию об организационных структурах или бизнес-процессах. Сфера может заполняться в направлении "снизу–вверх" путем сбора относящейся к предметной области информации, а на более высоких уровнях эта информация будет обобщаться. Либо же заполнение может идти в направлении "сверху–вниз" с постепенной декомпозицией на более мелкие детали.
После того как некоторая пара сфер определена с достаточной степенью детализации, элементы, составляющие эти сферы, могут быть связаны так, чтобы представить существующие в реальности связи между объектами анализа. Это обеспечивает возможность оптимизации и улучшений в различных областях деятельности предприятия.
Опыт показывает, что наибольшую важность представляют следующие сферы: цели и задачи, организация, бизнес-процессы, прикладные системы, технологии, проекты, бизнес-компоненты, данные, бизнес-функции, инфраструктура. Это отражено на рис. 9.2.
Рис. 9.2. Типичные сферы интересов SAM
Внутри каждой области интересов сохраняется информация о какой-то определенной предметной области, что обеспечивает простоту сопровождения и извлечения этой информации. Обычно применяется одна или более иерархическая структура, которые напоминают ящик с файлами. Минимальный объем информации, относящейся к какой-либо сфере, называется элементом (member). Например, элементами сферы "Местоположение" могут быть "Головной офис", "Офис продаж в санкт-Петербурге", "Завод в Волоколамске" и т.д. Другими примерами элементов различных сфер являются:
1. Конкретные подразделения, например, "Отдел продаж" в сфере "Организация".
2. Конкретные бизнес-процессы, например, "Прием заказа" в сфере "Бизнес-процессы".
3. Конкретные информационные объекты, такие как "Клиент" в сфере "Данные".
В принципе, наименования сфер говорят сами за себя. Отметим только, что под бизнес-компонентами понимается совокупность данных и тех бизнес-функций, которые создают, читают, обновляют и удаляют эти данные. Группировка всех функций, создающих и обновляющих одни и те же элементы данных с помощью процесса под названием "коммутативная кластеризация" позволяет определить неизбыточное количество "строительных блоков" – компонент – которые могут использоваться для построения систем и приложений, поддерживающих определенные бизнес-процессы. Компоненты являются важными конструкциями в современных подходах к разработке систем. Достаточно вспомнить про сервис-ориентированную архитектуру SOA и архитектуру MDA, основанную на моделях. Объединение (инкапсуляция) функциональности и данных позволяет на практике добиться повторного и многократного использования элементов систем и дает возможность замены одних элементов другими. Компоненты предлагают "сервисы", которые могут использоваться в совокупности с другими сервисами, предлагаемыми другими компонентами в рамках сервис-ориентированной архитектуры.
Важное замечание, отраженное на нашем рисунке, состоит в том, что можно выделить три категории сфер:
1. Стабильные. Эти сферы описывают достаточно стабильные элементы бизнеса и представляют фундаментальные структуры: бизнес-функции, данные, бизнес-компоненты и инфраструктуру.
2. Подвижные. Эти сферы описывают то, что предприятие делает или может делать с точки зрения бизнеса, в том числе для того чтобы обеспечить отличия от конкурентов и динамичность в своей деятельности. Сферы, которые относятся к этому разделу – организация, бизнес-процессы, прикладные системы и технологии – представляют собой области, которые организация может изменить достаточно быстро. Эти сферы могут, на самом деле, находиться в процессе постоянных изменений, для того чтобы обеспечить адекватную реакцию на экономические и рыночные условия.
3. Динамичные. Это те сферы, которые задают направления бизнеса, рабочие программы, управление изменениями. Они описывают основные области, в которых работает предприятие, и усилия, которые требуются для движения в сторону достижения целей и задач посредством связанных между собой проектов.
Эта классификация позволяет, во-первых, понимать, какая часть архитектуры вашего предприятия носит достаточно стабильный характер, а какая требует постоянных изменений. Во-вторых, это помогает идентифицировать достаточно стабильные области, для которых полезна разработка архитектурных шаблонов. Такими областями, в частности, являются бизнес-функции, данные, бизнес-компоненты и, в определенной степени, инфраструктура.
Дата добавления: 2019-02-12; просмотров: 1090; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!