Принципы, модели и стандарты в рамках архитектуры предприятия

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

Рис. 5.2. Модель, используемая для описания стратегии и архитектуры информационных технологий

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

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

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

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

· Миссия и видение.

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

· Цели, задачи и стратегии.

· Архитектура информационных технологий.

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

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

· Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе.

· Руководства или рекомендации (guidelines). Руководства и рекомендации – это описания лучших практик или приемлемых подходов к практической реализации политик и процедур. Руководства могут стать стандартами.

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

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

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

Рис. 5.3. Политики, стандарты и процедуры

Важным представляется следующее замечание, сформулированное в архитектурной методике META Group, которое касается роли принципов и моделей в описании архитектуры (более подробно об этом см. в "Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF"). Можно сказать, что существуют два различных подхода к процессам разработки, описания и использования архитектуры предприятия: существенная, возможно, даже большая часть специалистов и компаний считает, что основой архитектуры являются принципы, а другая часть придерживается точки зрения, что основой архитектуры является процесс создания моделей. META Group полагает, что при описании сегодняшней, существующей архитектуры (архитектуры "как есть") необходимо в большей степени руководствоваться декларациями принципов, на основе которой она построена; в то же время, будущие состояния архитектуры должны описываться с использованием соответствующих моделей, описывающих отдельные представления (домены) будущей архитектуры.

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

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

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

Эволюция содержания архитектуры предприятия по мере ее разработки и развития условно показана на рис. 5.4.

Рис. 5.4. Эволюция контента Архитектуры предприятия

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

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

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

Ниже приведены примеры общих принципов, связанных с архитектурой в целом:

· Все подразделения (ведомства) должны использовать в своей работе архитектуру, разработанную для организации (правительства) в целом.

· Функциональное руководство и руководство в области ИТ должно основываться на общем видении.

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

· Функциональные (бизнес-) требования должны формировать архитектуру.

· Архитектура должна обеспечивать совместимость и взаимодействие.

· Архитектура должна быть расширяемой, масштабируемой и адаптивной.

· Архитектура должна быть инструментом реализации изменений.

· Архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов.

· Тенденции рынка должны учитываться при проектировании технологической архитектуры.

Примеры декларируемых принципов в области ИТ-инфраструктуры:

· Инфраструктура должна быть основана на использовании технологий, поддерживающих открытые стандарты.

· Инфраструктура (совместно с принципами управления данными и разработки приложений) должна обеспечивать взаимодействие систем.

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

· Бизнес-структуры (отделы, департаменты, ведомства), являющиеся владельцами данных, отвечают за целостность и распространение данных.

· Данные уровня отдельных бизнес-структур (департамента, региона, города) должны быть явно описаны и доступны всем остальным бизнес-структурам (департаментам, ведомствам).

· Ведомства собирают только самый необходимый минимум данных и стремятся уменьшить нагрузку на тех, кто должен предоставлять данные.

· Данные вводятся в информационные системы один раз, и тут же выполняется проверка их корректности.

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

Примеры принципов, связанных с прикладными системами:

· Прикладные системы разрабатываются на основе стандартной, единой методологии.

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

· Создание межфункциональных прикладных систем приветствуется.

· Руководство заранее планирует процесс замены устаревших прикладных систем.

Примеры принципов, связанных с управлением и контролем:

· Единая архитектура, соответствующие стандарты и руководства используются всеми структурными подразделениями (ведомствами) в процессе принятия решений о своих информационных системах.

· Стандарты пересматриваются регулярно не реже одного раза в два года с участием представителей структурных подразделений (ведомств).

· Руководство структурных подразделений (ведомств) стремится к кооперации и партнерству с другими структурными подразделениями (ведомствами) в области информационных технологий.

Вот еще некоторые варианты формулировок принципов:

· организация должна иметь интегрированный процесс управления архитектурой.

· должны существовать механизмы управляемого развития архитектуры.

· целью архитектуры должно быть уменьшение сложности интеграции систем.

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

· Информация является общекорпоративным активом.

· Прикладные системы будут строиться с использованием n-уровневой архитектуры (презентационная логика, бизнес-логика, уровень доступа к данным, уровень данных).

· Для интерфейсов между системами будет использоваться технология пересылки сообщений.

· Применение компонентной разработки информационных систем.

· Использование технологий анализа данных (Business Intelligence) для ускорения принятия решений и упрощения разработки.

· ИТ-служба будет использовать стандарты и методику управления качеством "Шесть Сигма" в процессе обеспечения качества прикладных систем и ИТ-услуг (принцип, который может быть принят в результате анализа сильных и слабых сторон ИТ-службы).

Еще раз отметим, что эти принципы могут показаться слишком общими. Проще всего "списать" набор таких утверждений с чужих документов. Но дело в том, что принципы начинают работать только тогда, когда они являются результатом широкого и вдумчивого обсуждения с участием представителей различных структурных подразделений как со стороны бизнеса, так и сотрудников, отвечающих за ИТ, когда причины и последствия их принятия всеми хорошо осознаются и задокументированы и когда реализация этих принципов закреплена в конкретных процедурах.

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

При разработке и использовании стандартов следует учитывать нижеперечисленные аспекты [4.5], [4.6]:

· Уделяйте большее внимание тем стандартам, которые обеспечивают эффективное использование базовых технологий. Прежде всего, это технологии, на которых построены многие системы и которые стали индустриальными стандартами. Примерами таких технологий для организаций являются XML,.NET, Java (рассматриваемая не как язык, а как среда разработки).

· Определяйте стандарты процессов. Примерами являются процессы бизнес-моделирования, методы разработки систем, тестирования, интеграции.

· Уделяйте внимание интерфейсам. Понимание интерфейсов является основой для интеграции систем.

· Теснее взаимодействуйте с бизнес-подразделениями. Например, разработка основанных на XML стандартов на электронные сообщения невозможна без участия специалистов в конкретных предметных областях.

· Для того чтобы быть эффективным инструментом, стандарты должны включать списки конкретных версий технологий, интерфейсов программирования (API), утилит и т.д. Примерами могут быть версии систем управления базами данных, версии XML и т.п.

· Стандарты должны включать способы проверки на соответствие.

· Стандарты должны содержать описание того, как организован процесс их поддержки. Стандарты должны периодически пересматриваться и обновляться.

Руководства (рекомендации) обеспечивают помощь в разработке и создании систем, давая примеры лучших практик и конкретные руководства по выполнению чего-либо. Сделаем наиболее важные замечания, касающиеся руководств:

· Руководства не заменяют техническую документацию, но рассматривают некоторые проблемы в контексте конкретной организации.

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

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

· Наиболее эффективные руководства, как правило, короткие и специфичные. Желательно ограничивать их четырьмя страницами.

Дата добавления: 2015-04-25