Кпр. Архитектура (копия). Treasury Enterprise Architecture
 Скачать 0.74 Mb.
|
|
Раздел Протоколы и Стандарты описывает те промышленные протоколы и стандарты, которые должны поддерживаться используемыми в организации технологиями. Раздел Используемые продукты и технологии является, по сути дела, утвержденным для организации списком продуктов или технологий. Они закупаются и используются как для создания приложений, так и для формирования инфраструктуры и обеспечения интеграции с внешними системами. Эта часть содержит взвешенную оценку всех «за» и «против» о конкретных поставщиках. Таким образом, данный подход позволяет обеспечить отслеживание логической связи между выбранными технологиями, их ценностью для бизнеса и потребностями бизнеса. Выбор не должен быть сделан просто по той причине, что это «крутая» технология или что эта технология уже фактически используется. В 2002 году Gartner сформулировала новую концепцию архитектуры предприятия, которая стала определенным обобщением рассмотренной ранее модели ИТ-архитектуры на уровень Бизнес-архитектуры, косвенным отражением растущей важности вопросов взаимодействия предприятий между собой, влияния концепций сервис-ориентированной архитектуры, осознания того факта, что существуют различные стили архитектуры информационных систем, соответствующие различным стилям бизнес-процессов. Мы уже отмечали выше, что типичными стилями бизнес-процессов являются массовая обработка транзакций, операции в реальном времени, аналитические процессы и бизнес-анализ, совместная работа. Эта модель в какой-то степени расширяет рассмотренные выше представления, а также подчеркивает взаимосвязь между понятиями «Электронной нервной системы» предприятия, которые были сформулированы в свое время Биллом Гейтсом, основателем, а ныне Председателем и Главным архитектором программного обеспечения компании Microsoft, и практической реализации этих идей в рамках современных подходов к проектированию архитектуры ИТ предприятия. Кстати, обратите внимание, как называется должность Билла Гейтса. Не является ли это еще одним подтверждением важности вопросов систематического построения и описания архитектуры? Билл Гейтс в своей книге «Бизнес со скоростью мысли» дал следующее определение: «электронная нервная система есть совокупность электронных процессов, с помощью которых организации воспринимают мир и адекватно реагируют на изменения, происходящие в нем». Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней: Среда бизнес-взаимодействия (Business Relationship Grid); Бизнес-процессы и стили бизнес-процессов; Шаблоны; Технологические строительные блоки (кирпичики – bricks).  В этой схеме верхние два уровня ориентированы на совместное обсуждение с бизнес-руководителями и ИТ-специалистами и в какой-то степени соответствуют тому, что мы называли бизнес-архитектурой, а нижние два уровня входят во внутреннюю компетенцию ИТ-службы: верхний уровень Среды бизнес-взаимодействия описывает новую модель «виртуального» бизнеса, а также все, что связано с кооперацией предприятий и бизнесом B2B. Этот уровень соответствует понятию «отраслевой нервной системы» взаимодействующих предприятий. Он получил развитие в связи с распространением Интернета как среды взаимодействия, и связан с понятиями доступа, межорганизационного взаимодействия; второй уровень Стили бизнес-процессов описывает, как организация выполняет свои ключевые функции, т.е. включает в себя бизнес-процессы предприятия, такие как обработка заказа, мониторинг производственных процессов, анализ использования критически важных ресурсов, совместная работа с информацией; следующий уровень Шаблоны описывает модели и алгоритмы, которые могут широко использоваться для решения различных задач на предприятии. Отметим, что шаблоны охватывают не только область программного обеспечения, но и соответствующие сетевые и вычислительные ресурсы. Примерами шаблонов является трехуровневая архитектура прикладных систем (интерфейс-логика-данные), использование «толстого» клиента в архитектуре клиент/сервер, хранилища данных. Что касается приложений, то упор сделан на использовании шаблонов сервис-ориентированной архитектуры, т.е. реализации приложений в виде модульного набора различных типов сервисов. Это, в том числе, позволяет в перспективе интегрировать приложения как web-сервисы. нижний уровень Строительные блоки (Bricks) соответствует технологической архитектуре и включает в себя операционные системы, серверы, базы данных, сами данные и пр. Этот подход является адекватным с точки зрения того, что он раскрывает руководству механизм влияния решений в области ведения бизнеса на решения в области использования ИТ на предприятии. Как предлагают первые верхние два уровня модели, архитектура становится особенно важной по мере того, как модели ведения бизнеса развиваются в сторону все «более виртуальных» структур («расширенных организаций»), успех которых будет в существенной степени зависеть от рациональной реализации архитектуры. Полная модель представляет собой «трехмерную» комбинацию бизнес-архитектуры, технической и информационной архитектур. При этом описанные выше слои среды бизнес-взаимодействия, стилей бизнес-процессов, шаблонов и строительных блоков пересекаются со слоями Информационной архитектуры (Домен данных, Домен приложений, Домен интеграции, Домен доступа) и Технической архитектуры (Домен инфраструктуры, Домен системного управления и Домен безопасности). По большому счету, «все пересекается со всем». Например, при построении прикладных систем могут использоваться шаблоны проектирования и строительные технологические блоки. При этом для управления прикладной системы используются технологии системного управления и также должны быть учтены вопросы безопасности. Данный подход Gartner представляет собой пример реализации методологии достаточно высокого уровня. Он задает только общую рамочную модель описания и фактически не определяет ни форматов, ни какого-либо специализированного языка для описания. Что касается разработки архитектуры, то в данном подходе сформулированы важные и полезные рекомендации в виде последовательности шагов и задач участников, которые, однако, не детализированы до уровня моделей процесса разработки архитектуры. 3.2. Методика META Group. Подробное описание методики разработки архитектуры предприятия META Group содержится в документе Enterprise Architecture Desk Reference объемом около 380 страниц, который предоставлялся клиентам компании. Остановимся на самых главных моментах этой безусловно интересной методики, доступных в открытых материалах. По мнению META Group, «архитектура является одновременно некоторым структурированным описанием информационных технологий предприятия и его информационных технологий (т.е. конечным результатом, включающим определенные артефакты-стандарты, утверждения, касающиеся общего видения, архитектурные документы), процессом создания и обновления артефактов архитектуры и группами людей, вовлеченных в этот процесс». Соответственно этим представлениям методика компании уделяет достаточно подробное внимание всем трем составляющим архитектуры. При этом отличительной особенностью методики META является более детальное и формализованное описание именно процесса разработки архитектуры и всех его составляющих. Исторически архитектурная методика 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). Организация рабочего процесса разработки архитектуры и быстрое создание начальной версии архитектуры предприятия, согласно META Group, состоит в прохождении следующих этапов. На этапе 1 разрабатывается Видение общих требований. Разработка Видения общих требований включает в себя: -анализ тенденций развития внешней для предприятия среды, включая технологические тенденции; - бизнес-стратегии и основные движущие силы с точки зрения бизнеса; - требования к информационным системам со стороны бизнеса; -требования к технологической архитектуре, которая обеспечивает адекватные возможности для информационных систем с точки зрения потребностей бизнеса. Этап 2 состоит в разработке Концептуальной архитектуры, которая определяет логически связанный набор принципов, обеспечивающий общее руководство для развития информационных систем предприятия и технологической инфраструктуры. На этом же этапе параллельно ведется разработка наиболее приоритетных доменов архитектуры. Здесь же выполняется анализ на несоответствие (gap-анализ) между текущим и желаемым состоянием архитектуры. Этап 3 состоит в разработке плана реализации, обеспечивающего миграцию в сторону желаемого состояния архитектуры. При этом данная методика предлагает формализованные шаблоны, обеспечивающие разработку Видения общих требований и Концептуальной архитектуры. Рекомендация относительно Видения общих требований состоит в том, что этот документ не должен обязательно быть исключительно точным и всеобъемлющим с точки зрения анализа бизнес-стратегии. Главное – это совместное участие представителей бизнес-подразделений и ИТ в выработке общего понимания набора требований, согласованных со стратегическим направлением развития компании. Размер этого документа может быть 10-15 страниц. Основное содержание документа может состоять из четких утверждений, которые тематически связаны между собой. Важный аспект заключается в документировании явных связей между бизнес-стратегией (потребностями бизнеса) и требованиями к информационным системам и, в конечном итоге, установления логических связей с требованиями к технологической архитектуре. Для этого рекомендуется использовать простые матрицы. Пример - матрица связей между бизнес-стратегиями, требованиями к информационным системам и технологической архитектуре Документированные связи послужат основой для будущих решений об инвестициях. Таким образом, результатом первого этапа работ могут быть четыре документа: - список ключевых технологических тенденций; - список бизнес-стратегий; - список требований к информационным системам; - список требований к технологической архитектуре. Видение общих требований агрегирует все требования к технологической архитектуре, и это служит основой для формулировки принципов Концептуальной архитектуры. В свою очередь, эти принципы обеспечивают общие руководства в использовании, разработке различных информационных систем и инфраструктуры в различных технологических областях. Концептуальная архитектура разрабатывается еще до создания других архитектурных доменов и основана на принципах, которые имеют несколько общих характеристик: -принципы представляют собой содержательные утверждения, которые касаются архитектурного процесса или содержания архитектуры; - принципы являются ограниченным числом точек стабильности, на которых строится архитектура; - принципы должны быть утверждениями, чья справедливость для организации носит «вечный» характер, поскольку они задают систему ценностей для архитектуры в целом. Мы уже отмечали, что в соответствии с методикой META Group результатом разработки принципов концептуальной архитектуры является выделение в технологической архитектуре (EWTA) набора доменов (предметных областей), которые объединяют группы связанных между собой технологий и компонент. При этом, можно выделить два различных типа доменов технологической архитектуры: базовые (технологии, которые используются практически каждой информационной системой: сети, аппаратное обеспечение, операционные системы, системы хранения, программное обеспечение промежуточного слоя, системы управления базами данных, технологии системного управления ИТ-ресурсами в распределенной среде, архитектура безопасности) и прикладные (более специфические с точки зрения использования бизнесом технологии: системы коллективной работы, электронной почты и управления потоками работ (workflow), Интранет, Интернет-приложения, системы электронной коммерции, архитектура хранилищ данных, специализированное аппаратное обеспечение). Каждый домен технологической архитектуры включает описание принципов, технологий, стандартов, продуктов, конфигураций, лучших практик, которые являются многократно используемыми строительными блоками при построении ИТ-систем. Таким образом, документ, описывающий каждый домен технологической архитектуры, включает следующие компоненты: Формулировка миссии домена: стратегические цели домена. Описание компонентов домена: это обеспечивает общее понимание включенных в домен технологий. Принципы проектирования, принятые в домене. Они определяют правила, применяемые в процессе принятия решений в отношении технологий домена, а также обоснования и последствия принятия этих принципов. Здесь могут быть построены матрицы соответствия между требованиями к технологической архитектуре (RTA), сформулированные в процессе создания Видения общих требований, и принципов проектирования, принятых для конкретного домена. Стандарты: продукты и технические стандарты, которые обеспечивают требования к технологической архитектуре. Выделяют стратегические (предпочтительные) стандарты, переходные (которые используются временно), устаревшие (которые, возможно, еще используются, но от которых организация отказывается) и исследовательские или новые (которые находятся только на этапе рассмотрения и апробации). Лучшие практики. Конфигурации. Они формулируются в тех случаях, когда нужно уменьшить сложность принятия решений или когда можно уменьшить общую стоимость владения за счет стандартных конфигураций. Несоответствия между существующим состоянием домена технологической архитектуры и желаемым состоянием. Это служит основой для последующих работ группы, которая отвечает за данный домен архитектуры. В ряде публикаций представления о технологической архитектуре META Group получили дальнейшее развитие и дополнены такими аспектами, как инфраструктурные шаблоны и инфраструктурные сервисы. Это связано с общей для индустрии ИТ тенденцией уделять большое внимание шаблонам проектирования, а также с развитием принципов сервис-ориентированной архитектуры. Отмечается, что инфраструктурные шаблоны должны обеспечивать взаимодействие и интеграцию различных технологий, указывать область применимости шаблона для конкретного типа прикладной системы (транзакционные, публикация информации, совместная работа). Примерами таких инфраструктурных шаблонов являются шаблоны выполнения транзакций (одноуровневые, двухуровневые транзакции, трех- и n-уровневые транзакции), шаблоны публикации информации (публикация клиент/сервер, web-публикация, видео- и аудио-поток), шаблоны взаимодействия (взаимодействие в реальном времени, взаимодействие по схеме «запомнил–переслал», структурированное взаимодействие). Взгляд на технологическую архитектуру с точки зрения предоставляемых ею инфраструктурных сервисов обусловлен распространением принципов сервис-ориентированной архитектуры. Это связано с описанием, например, сервисов презентации информации (порталы, настольные системы и пр.), сетевыми сервисами (LAN, WAN, удаленный доступ), сервисами безопасности (управление пользователями, доступ), сервисами хранения данных (SAN – Storage Area Network, файловые системы), сервисами баз данных (OLTP), интеграционными сервисами, платформенными сервисами, которые используются прикладными системами. При этом архитектурные домены, шаблоны и сервисы обеспечивают наращивание уровней адаптируемости технологий предприятия: Домены архитектуры – первый уровень адаптируемости технологий. Категоризация помогает предприятиям обнаруживать излишние технологии, продукты и конфигурации, а также позволяет идентифицировать возможности многократного использования элементов технологической архитектуры. Шаблоны – второй уровень адаптируемости технологий. Позволяют разработчикам использовать одни и те же конфигурации технологий для решения похожих задач. Сервисы – третий уровень адаптируемости технологий. Они обеспечивают общие интерфейсы для разработчиков прикладных систем и интеграторов приложений в рамках всей инфраструктуры предприятия. При этом выделяется четыре группы сервисов по мере повышения уровня абстракции: Базовые инфраструктурные сервисы: общие, стандартные технологии, широко используемые в рамках всех ИТ-систем предприятия. Они ориентированы не на разработчиков прикладных систем, а на специалистов по инфраструктуре. Примерами являются ПО пересылки сообщений промежуточного слоя, мониторы транзакций, сервисы каталогов. Общие (framework) инфраструктурные сервисы: общие, совместно используемые технологии, которые не содержат готовой бизнес-логики (хотя она и может быть запрограммирована), ориентированы на разработчиков и могут быть не полностью стандартизированы. Примерами таких сервисов являются управление контентом, серверы приложений, серверы выполнения бизнес-правил. Общие (framework) бизнес-сервисы: могут быть использованы в рамках различных бизнес-процессов, поскольку они содержат готовую, предопределенную бизнес-логику. Примерами таких сервисов являются модули определения цены товара, модули персонализации информации, модули оценки кредитного рейтинга. Прикладные бизнес-сервисы: специфические для отдельных бизнес-процессов, содержат высокоуровневую бизнес-логику. Например, сервисы CRM-систем или систем управления поставками. В результате получается технологическая модель предприятия. В полном описании методики META Group приводятся также следующие аспекты: - практическая реализация архитектуры через процесс управления корпоративными ИТ-программами и проектами; - вопросы управления и контроля архитектурного процесса (governance); - оценка зрелости архитектуры; - анализ технологических тенденций и планирование; - управление портфелем ИТ-активов и проектов. 3.3. Методика TOGAF. Методика описания архитектуры TOGAF (сокращение от The Open Group Architecture Framework) была предложена некоммерческим объединением The Open Group, в которое входит ряд ведущих производителей информационных технологий, а также компаний из списка Fortune 1000. TOGAF позиционируется ее авторами не как некоторая эталонная модель, а как «средство для разработки архитектур информационных систем». Основное назначение – ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития. В декабре 2003 года была опубликована версия 8.1 этой модели. Представление архитектуры предприятия в методологии TOGAF показано на рисунке 3. Рисунок 3. Представление архитектуры предприятия в методологии TOGAF. Как показано на рисунке 3, в модели TOGAF архитектура предприятия подразделяется на четыре категории: Архитектура бизнеса — описывает процессы, используемые для достижения бизнес-целей Архитектура приложений — описывает структуру конкретных приложений и их взаимодействие друг с другом Архитектура данных — описывает структуру корпоративных хранилищ данных и процедуры доступа к ним Технологическая архитектура — описывает инфраструктуру оборудования и программного обеспечения, в которой запускаются и взаимодействуют приложения Модель TOGAF позиционируется как «структура», однако наиболее важным ее компонентом является методика разработки архитектуры (ADM). Эта методика представляет собой рецепт по созданию архитектуры. Рецепт можно классифицировать как процесс. С учетом того, что методика разработки архитектуры является наиболее значимой составляющей модели TOGAF, я рассматриваю TOGAF в целом как архитектурный процесс, а не как архитектурную структуру (как позиционирует TOGAF консорциум The Open Group) или методологию (как позиционируется методика разработки архитектуры). Как архитектурный процесс модель TOGAF дополняет модель Захмана. Захман показывает, как следует классифицировать артефакты. Модель TOGAF описывает процесс создания артефактов. В модели TOGAF мир архитектуры предприятия рассматривается как континуум архитектур, от максимально обобщенных до максимально специализированных. Этот континуум называется континуумом предприятия. Процесс создания конкретной архитектуры предприятия, например MAM-EA, рассматривается как переход от общей архитектуры к специализированной. Методика разработки архитектуры в модели TOGAF представляет собой процесс осуществления т В модели TOGAF наиболее обобщенные архитектуры называются фундаментальными архитектурами. Эти принципы построения архитектуры теоретически могут использоваться практически любой ИТ-организацией в мире. Следующий уровень специализации в модели TOGAF называется общесистемными архитектурами. Эти принципы прослеживаются во многих — возможно, не во всех — типах предприятий. Следующий уровень специализации в модели TOGAF называется отраслевыми архитектурами. Эти принципы характерны для предприятий, занятых в одной сфере деятельности, например, для всех фармацевтических компаний. Самый высокий уровень специализации в модели TOGAF называется архитектурами организаций. Это архитектуры конкретных предприятий. Основным полем для применения TOGAF является, прежде всего, программная инфраструктура информационной системы (в противоположность таким типам архитектур, как бизнес-архитектура, архитектура данных и приложений). Таким образом, она в наилучшей мере подходит для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса (mission-critical). Поскольку эта интеграционная архитектура сильно зависит от принимаемых решений в остальных областях, то в рамках TOGAF в необходимой степени рассматриваются и эти смежные области. В состав модели TOGAF входят две основные компоненты – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Заметим, что в описании TOGAF добавлен специальный документ, поясняющий соответствие между понятиями TOGAF и моделью Захмана. В модели TOGAF на уровне фундаментальных архитектур определяется ряд баз знаний. Вы можете столкнуться с двумя из них: технической эталонной моделью (TRM) и информационной базой стандартов (SIB). Техническая эталонная модель является рекомендуемым описанием общей ИТ-архитектуры. Информационная база стандартов представляет собой набор стандартов и псевдостандартов, которые консорциум The Open Group рекомендует использовать при построении ИТ-архитектуры. В TOGAF техническая эталонная модель и информационная база стандартов рекомендуются к использованию, но не являются обязательными. Существует мнение, что и техническая эталонная модель, и информационная база стандартов не лишены недостатков по следующей причине: они направлены на обеспечение переносимости приложений в ущерб их способности к взаимодействию и автономности; и что такое представление технических архитектур устарело. Для конкретных организаций модель TOGAF в значительной степени сводится к методике разработки архитектуры. Сотрудники конкретной организации будут работать с континуумом предприятия, информационной базой стандартов и технической эталонной моделью (а также с рядом других возможностей TOGAF); именно поэтому эти возможности и были рассмотрены здесь. Однако для каждодневного создания архитектуры предприятия в основном используется методика разработки архитектуры, высокоуровневое представление которой показано на рисунке 5. Как показано на рисунке 5, методика разработки архитектуры в модели TOGAF состоит из восьми этапов, которые циклически повторяются после первой «накачк Рисунок 5. Методика разработки архитектуры (ADM) в модели TOGAF. Методология TOGAF весьма гибкая, а детали реализации архитектурных артефактов могут быть различны. В одной из книг по TOGAF говорится: «Методология TOGAF — это не только и не столько создаваемые документы; фактически она в меньшей степени ориентирована на шаблоны документов, а в большей — на то, что мы получаем на входе и на выходе». Спецификация TOGAF также позволяет гибко работать с этапами. В самой спецификации говорится следующее: Перед применением методики разработки архитектуры необходимо проверить компоненты на применимость, а затем связать их с конкретными обстоятельствами отдельного предприятия. Это позволяет создать методику разработки архитектуры для конкретного предприятия. Модель TOGAF позволяет выполнять этапы частично, пропускать их, объединять, изменять порядок и вносить изменения в соответствии с конкретными требованиями. Неудивительно, что два сертифицированных консультанта по TOGAF могут разработать два совершенно различных процесса — даже при работе с одной и той же организацией. Модель TOGAF обладает еще большей гибкостью в отношении созданной архитектуры. Фактически TOGAF, как это ни удивительно, «ничего не знает» об архитектуре. Окончательная архитектура может с одинаковым успехом быть хорошей, плохой или неопределенного качества. В TOGAF описывается, как создать архитектуру предприятия, но не описывается, как создать хорошую архитектуру. Качество конечного продукта зависит от опыта персонала компании и консультанта по TOGAF. Те, кто внедряет TOGAF в надежде получить чудодейственное средство, будут жестоко разочарованы (впрочем, как и при использовании любой одной методологии). .Методы управления и контроля архитектуры предприятия. Создание организационных структур и выстраивание процесса управления разработкой, практическим использованием и обеспечением соответствия принятой архитектуре является одним из ключевых факторов успеха. Для этого процесса в английском языке используется термин "governance". Таким образом, эта функция управления и контроля включает два аспекта: обеспечение того, что архитектура предприятия становится правилом или "законом", которому все подразделения организации, специалисты по ИТ следуют в своей работе. Очень часто хорошие планы остаются благими намерениями, поскольку отсутствуют достаточно авторитетные структуры, которые превратили бы план в "закон". Таким образом, нужен адекватный организационный механизм, который бы делал результаты работы группы, отвечающей за разработку архитектуры, законом для всего предприятия; организация процесса, который бы обеспечил выполнение принятых правил (или "закона"). Это включает процессы рассмотрения проектов и инициатив на соответствие архитектуре, процессы рассмотрения неизбежных исключений и конфликтов – фактически, обеспечение контроля и надзора. Реализация управления и контроля естественно предполагает участие представителей бизнес-подразделений в работе над архитектурой. То есть управление и контроль архитектурного процесса включает такие аспекты, как персонал, правила (политики) и процессы, которые должны обеспечивать средства обеспечения свободы действий и принятия решений без нарушения общих правил, установленных архитектурой. Это предполагает принятие правил и выработку руководств, которые бы задавали стандарты поведения по отношению к архитектуре предприятия. А за этим следует определение способов выполнения правил, т.е. процессов, обеспечивающих исполнение этих правил и руководств (включая методы контроля, список контролируемых параметров, информирование и применение санкций, связанных с несоблюдением правил). Вообще говоря, следует отличать понятие управления и контроля архитектурного процесса от более широкого понятия управления и контроля использования ИТ на предприятии в целом. Мы ранее говорили о том, что разработка архитектуры строится на основе двух групп механизмов. Первая группа механизмов – это архитектурные принципы: условно говоря, "неявные" (implicit – по аналогии с принципами управления знаниями) механизмы. Вторая группа механизмов описания архитектуры включает определение формальных стандартов, моделей и требований, – "явные" (explicit) инструменты и механизмы. Важный аспект заключается в том, что инструменты управления и контроля архитектурного процесса должны включать различные способы, которые предполагают обеспечение соответствия как "неявным" элементам архитектуры (принципам), так и "явным" (стандартам). Обеспечение следования принципам достигается прежде всего через "мягкие" механизмы: информирование и коммуникации, обеспечение общего понимания и добровольного принятия. Обеспечение выполнения стандартов и правил как части архитектуры требует более "жестких" формальных механизмов, таких как формальные процедуры рассмотрения и проверок, процедуры рассмотрения исключений из правил, штрафные санкции. Заметим, что само понятие "соответствие" нетривиально и будет более подробно обсуждаться далее в лекции 11. В тех же случаях, когда по определенным, явно сформулированным и обоснованным бизнес-причинам какая-либо система или прикладное решение не может соответствовать принятой архитектуре, в рамках функции надзора необходимо обеспечить, чтобы функциональные и бизнес-подразделения понимали реальную стоимость реализации и использования таких несоответствующих архитектуре систем и решений. Эта дополнительная стоимость может быть связана с более высокими затратами на эксплуатацию или отсутствием гибкости в дальнейшем развитии решений. Точно так же, как и во многих других областях, формирование структур и процессов управления и контроля архитектуры предприятия лучше всего начать с формулировки руководящих принципов. Приведем только некоторые из них, которые нам представляются достаточно важными и универсальными: Архитектура новых систем будет проходить формальные процедуры контроля на эффективность. Предлагаемые изменения в бизнес-процессах и системах будут контролироваться с точки зрения их влияния на другие обеспечивающие их бизнес-процессы и системы. Набор моделей архитектуры будет поддерживаться в актуальном состоянии (в специальном репозитории), целостность моделей и связи между ними также будут контролироваться и обеспечиваться. Будут разработаны и поддерживаться стандарты и правила (политики). Соответствие стандартам и правилам будет контролироваться. Архитектура будет неотъемлемой частью всего процесса управления ИТ на предприятии. Технологическая архитектура будет контролироваться на уровне предприятия в целом. Команда проекта разработки архитектуры, выполняющая основную работу, не является собственником этого процесса и результатов. Результаты разработки формируются в виде рекомендаций, подлежащих утверждению высшим руководством организации для придания определенной значимости и легитимности. Вообще говоря, наиболее общими подходами обеспечения управления и контроля архитектуры являются следующие: Публикации и распространение информации и документов описания архитектуры. Подход, который можно охарактеризовать так: "Подайте пример, и люди сами за вами потянутся". На самом деле, публикация архитектурных документов является очень важным аспектом всего процесса управления архитектурой, но сам по себе этот инструмент не будет работать без других механизмов. С разработкой и реализацией архитектуры предприятия связаны интересы большого количества сторон, поэтому информация об архитектуре должна распространяться внутри организации на различных уровнях, в том числе с использованием визуальных, графических средств представления или специализированных языков. Для высшего руководства архитектура должна демонстрировать, как она обеспечивает достижение бизнес-целей и какие преимущества будут получены. Областью интереса бизнес-пользователей являются их специфические предметные области и функциональные потребности. Руководители в области ИТ и технический персонал больше сфокусированы на технических компонентах, включая то, как впоследствии будет обеспечиваться поддержка и сопровождение разрабатываемых решений. Архитекторов отдельных проектов волнуют такие вопросы, как стандарты, шаблоны и правила, пригодные для повторного использования либо накладывающие ограничения на дизайн отдельных решений. Публикуя информацию об архитектуре, нужно стремиться удовлетворить все перечисленные категории заинтересованных сторон. Более того, чем более открытой является эта информация внутри предприятия (за исключением, возможно, определенных аспектов архитектуры безопасности), тем больший эффект это принесет. Создание формальных структур, таких как Совет по архитектуре. На регулярных заседаниях таких формальных структур должны рассматриваться, в частности, архитектурные вопросы новых систем и инициатив. Эти структуры должны утверждать или отвергать проекты, в зависимости от того, насколько соблюдены принятые в архитектуре принципы, модели и стандарты. Большим преимуществом является ситуация, когда методики разработки систем и процессов управления проектами широко известны и используются в организации и когда рассмотрение проекта Советом по архитектуре является стандартным этапом процесса. Конечно, возможность этого комитета говорить "да" или "нет" по поводу проектов является важной, но даже сам факт наличия формального процесса рассмотрения проектов на соответствие архитектуре имеет колоссальный положительный эффект. Недостатками этого метода управления могут оказаться: дополнительный уровень бюрократии, отсутствие у комитета реальных рычагов изменения проектировочных решений, возможность задержек в рассмотрении вопросов в ситуации, когда требуется быстрое принятие решений. Контроль процесса закупок. Предполагается такое выстраивание процесса, когда закупка продуктов и технологий, соответствующих архитектуре, выполняется легко и просто, а покупка нестандартных с точки зрения принятой архитектуры продуктов существенно затруднена. Обеспечение связи между процессом закупок информационных технологий и стандартов архитектуры является ключевым способом институализации архитектуры и ее "внедрения" в культуру деятельности предприятия. Обеспечение консультирования по вопросам архитектуры. Это наиболее эффективный, имеющий минимальный уровень бюрократии процесс управления архитектурой. Он состоит в использовании ресурсов внутренних консультантов по вопросам архитектуры на самых ранних этапах проектов; они дают рекомендации, касающиеся выбора технологий и общих принципов проектирования системы. В отличие от формальных методов контроля, рассмотрения на комитетах и т.д., модель, предполагающая консультирование, является проактивной и упреждающей. Конечно, и у этого способа есть свои ограничения, поскольку есть опасность, что ограниченные ресурсы группы, отвечающей за разработку архитектуры, станут чрезмерно распыляться на работу по отдельным проектам. На самом деле, наиболее эффективным способом является сочетание всех перечисленных выше подходов на различных этапах реализации ИТ-проектов и систем так, как показано на рис. 11.1. Например, создание документов с описанием элементов архитектуры, таких как шаблоны проектирования, позволяет передать сообществу ИТ-специалистов информацию о коллективном передовом опыте, что важно в самом начале любого проекта. Это задает общую основу для архитектуры конкретного решения и используемых технологий.  |