Cтруктура и модель описания ИТ-архитектуры Gartner
В данном разделе мы кратко изложим подходы к описанию архитектуры, предложенные Gartner и представленные в материалах открытого доступа. Более подробно эти модели описываются в соответствующих публикациях (например, [5.10]-[5.11], предоставляемых клиентам компании. Одним из возможных, достаточно простых форматов описания архитектуры является простое матричное представление, которое для каждой из основных областей архитектуры ИТ, таких как данные, приложения, интеграция, общие сервисы, и инфраструктура, "последовательно накладывает" несколько спецификаций, отличающихся по уровню детализации и конкретизации: · Бизнес-потребности, которые определяют ключевые требования к конкретной технологии для данной индустрии и организации. Фактически здесь определяется индивидуальность архитектуры. Другой важный аспект связан с позиционированием ИТ в организации – либо ИТ-архитектура формируется для максимального уменьшения издержек, либо она должна обеспечивать возможности быстрых изменений и высокую гибкость. Другие примеры могут включать быстрое распространение информации, высокую безопасность, простоту использования и требуемую степень надежности. · Принципы, которые включают в себя те основополагающие подходы, которых придерживается руководство. Например, это может быть принцип максимального использования стандартных приложений вместо заказных разработок, правила относительно того, кто владеет данными и пр. Большинство организаций могут иметь от 20 до 30 таких базовых принципов. · Процессы и руководства во всех областях жизненного цикла элементов архитектуры. Этот раздел может охватывать такие области как документирование требований пользователей, стили программирования, процессы обеспечения качества или управление конфигурациями устройств и систем. Здесь также могут быть определены "эталонные модели" для организации пользовательского интерфейса, доступа к данным, управления содержанием. · Раздел Протоколы и Стандарты описывает те промышленные протоколы и стандарты, которые должны поддерживаться используемыми в организации технологиями. · Раздел Используемые продукты и технологии является, по сути дела, утвержденным для организации списком продуктов или технологий. Они закупаются и используются как для создания приложений, так и для формирования инфраструктуры и обеспечения интеграции с внешними системами. Эта часть содержит взвешенную оценку всех "за" и "против" о конкретных поставщиках. Таким образом, данный подход позволяет обеспечить отслеживание логической связи между выбранными технологиями, их ценностью для бизнеса и потребностями бизнеса. Выбор не должен быть сделан просто по той причине, что это "крутая" технология или что эта технология уже фактически используется. В 2002 году Gartner сформулировала новую концепцию архитектуры предприятия, которая стала определенным обобщением рассмотренной ранее модели ИТ-архитектуры на уровень Бизнес-архитектуры, косвенным отражением растущей важности вопросов взаимодействия предприятий между собой, влияния концепций сервис-ориентированной архитектуры, осознания того факта, что существуют различные стили архитектуры информационных систем, соответствующие различным стилям бизнес-процессов. Мы уже отмечали выше, что типичными стилями бизнес-процессов являются массовая обработка транзакций, операции в реальном времени, аналитические процессы и бизнес- анализ, совместная работа. Эта модель в какой-то степени расширяет рассмотренные выше представления, а также подчеркивает взаимосвязь между понятиями "Электронной нервной системы" предприятия, которые были сформулированы в свое время Биллом Гейтсом, основателем, а ныне Председателем и Главным архитектором программного обеспечения компании Microsoft, и практической реализации этих идей в рамках современных подходов к проектированию архитектуры ИТ предприятия. Кстати, обратите внимание, как называется должность Билла Гейтса. Не является ли это еще одним подтверждением важности вопросов систематического построения и описания архитектуры? Билл Гейтс в своей книге "Бизнес со скоростью мысли" [5.12] дал следующее определение: "электронная нервная система есть совокупность электронных процессов, с помощью которых организации воспринимают мир и адекватно реагируют на изменения, происходящие в нем". Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней: · Среда бизнес-взаимодействия (Business Relationship Grid); · Бизнес-процессы и стили бизнес-процессов; · Шаблоны; · Технологические строительные блоки (кирпичики – bricks).
При этом уровни ИТ-архитектуры соответствуют различным уровням выполнения операций реального бизнеса так, как показано на рис. 8.4.
В этой схеме верхние два уровня ориентированы на совместное обсуждение с бизнес-руководителями и ИТ-специалистами и в какой-то степени соответствуют тому, что мы называли бизнес-архитектурой, а нижние два уровня входят во внутреннюю компетенцию ИТ-службы: · верхний уровень Среды бизнес-взаимодействия описывает новую модель "виртуального" бизнеса, а также все, что связано с кооперацией предприятий и бизнесом B2B. Этот уровень соответствует понятию "отраслевой нервной системы" взаимодействующих предприятий. Он получил развитие в связи с распространением Интернет как среды взаимодействия, и связан с понятиями доступа, межорганизационного взаимодействия; · второй уровень Стили бизнес-процессов описывает, как организация выполняет свои ключевые функции, т.е. включает в себя бизнес-процессы предприятия, такие как обработка заказа, мониторинг производственных процессов, анализ использования критически важных ресурсов, совместная работа с информацией; · следующий уровень Шаблоны описывает модели и алгоритмы, которые могут широко использоваться для решения различных задач на предприятии. Отметим, что шаблоны охватывают не только область программного обеспечения, но и соответствующие сетевые и вычислительные ресурсы, как мы рассматривали ранее в "Технологическая архитектура, стандарты и шаблоны". Примерами шаблонов является трехуровневая архитектура прикладных систем (интерфейс-логика-данные), использование "толстого" клиента в архитектуре клиент/сервер, хранилища данных. Что касается приложений, то упор сделан на использовании шаблонов сервис-ориентированной архитектуры, т.е. реализации приложений в виде модульного набора различных типов сервисов. Это, в том числе, позволяет в перспективе интегрировать приложения как web-сервисы. · нижний уровень Строительные блоки (Bricks) соответствует технологической архитектуре и включает в себя операционные системы, серверы, базы данных, сами данные и пр. Этот подход является адекватным с точки зрения того, что он раскрывает руководству механизм влияния решений в области ведения бизнеса на решения в области использования ИТ на предприятии. Как предлагают первые верхние два уровня модели, архитектура становится особенно важной по мере того, как модели ведения бизнеса развиваются в сторону все "более виртуальных" структур ("расширенных организаций"), успех которых будет в существенной степени зависеть от рациональной реализации архитектуры. Полная модель [5.13] представляет собой "трехмерную" комбинацию бизнес-архитектуры, технической и информационной архитектур. При этом описанные выше слои среды бизнес-взаимодействия, стилей бизнес-процессов, шаблонов и строительных блоков пересекаются со слоями Информационной архитектуры (Домен данных, Домен приложений, Домен интеграции, Домен доступа) и Технической архитектуры (Домен инфраструктуры, Домен системного управления и Домен безопасности. По большому счету, "все пересекается со всем". Например, при построении прикладных систем могут использоваться шаблоны проектирования и строительные технологические блоки. При этом для управления прикладной системы используются технологии системного управления и также должны быть учтены вопросы безопасности. Данный подход Gartner представляет собой пример реализации методологии достаточно высокого уровня. Он задает только общую рамочную модель описания и фактически не определяет ни форматов, ни какого-либо специализированного языка для описания. Что касается разработки архитектуры, то в данном подходе сформулированы важные и полезные рекомендации в виде последовательности шагов и задач участников, которые, однако, не детализированы до уровня моделей процесса разработки архитектуры.
|