АКИС (10) - Лекция №9 - Бизнес-архитектура

Бизнес-архитектура

Построение бизнес-архитектуры начинается с общего обзора ситуации, который предполагает поиск ответов на следующие вопросы:

1. Каков внешний контекст деятельности организации?
2. В чем состоят основные функции и добавочная стоимость, которая является итогом деятельности организации?
3. Какие сценарии развития бизнеса необходимо учитывать, и какова вероятность их реализации?
4. Какие необходимы информационные взаимосвязи и процессы обработки информации?

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

А преимущества от построения таких моделей лежат в двух плоскостях: дополнительных возможностях для бизнеса и уменьшении затрат. По оценкам, создание бизнес-моделей и связанная с этим оптимизация затрат даже без радикальных изменений бизнеса может дать до 10% экономии.

А при моделировании альтернативных вариантов бизнес-процессов организации могут сэкономить до 20%. Но не менее важная роль бизнес-моделей состоит в том общем языке, которые они дают представителям бизнеса и ИТ в обсуждении соответствующих возможностей.

Принципы, модели и стандарты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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