Элементы Архитектуры предприятия. Бизнес-архитектура и архитектура информации

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

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

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

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

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

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

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

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

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

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

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

• организация должна иметь интегрированный процесс управления архитектурой.
• должны существовать механизмы управляемого развития архитектуры.
• целью архитектуры должно быть уменьшение сложности интеграции систем.
• организация будет "разрабатывать" те прикладные системы, которые связаны с получением конкурентных преимуществ, и "покупать" стандартные прикладные системы в тех областях, где достаточно иметь паритет по отношению к другим участникам рынка.
• Информация является общекорпоративным активом.
• Прикладные системы будут строиться с использованием n-уровневой архитектуры (презентационная логика, бизнес-логика, уровень доступа к данным, уровень данных).
• Для интерфейсов между системами будет использоваться технология пересылки сообщений.
• Применение компонентной разработки информационных систем.
• Использование технологий анализа данных (Business Intelligence) для ускорения принятия решений и упрощения разработки.
• ИТ-служба будет использовать стандарты и методику управления качеством "Шесть Сигма" в процессе обеспечения качества прикладных систем и ИТ-услуг (принцип, который может быть принят в результате анализа сильных и слабых сторон ИТ-службы).

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

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

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

• Уделяйте большее внимание тем стандартам, которые обеспечивают эффективное использование базовых технологий. Прежде всего, это технологии, на которых построены многие системы и которые стали индустриальными стандартами. Примерами таких технологий для организаций являются XML, .NET, Java (рассматриваемая не как язык, а как среда разработки).
• Определяйте стандарты процессов. Примерами являются процессы бизнес-моделирования, методы разработки систем, тестирования, интеграции.
• Уделяйте внимание интерфейсам. Понимание интерфейсов является основой для интеграции систем.
• Теснее взаимодействуйте с бизнес-подразделениями. Например, разработка основанных на XML стандартов на электронные сообщения невозможна без участия специалистов в конкретных предметных областях.
• Для того чтобы быть эффективным инструментом, стандарты должны включать списки конкретных версий технологий, интерфейсов программирования (API), утилит и т.д. Примерами могут быть версии систем управления базами данных, версии XML и т.п.
• Стандарты должны включать способы проверки на соответствие.
• Стандарты должны содержать описание того, как организован процесс их поддержки. Стандарты должны периодически пересматриваться и обновляться.

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

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