Контекст Архитектуры предприятия

 

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

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

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

· бизнес, включая движущие силы (ключевые факторы), видение и стратегию;

· организационные структуры и сервисы, которые требуются для реализации этого видения и стратегии;

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

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

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

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

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

· автоматизации процессов – там, где видится положительный возврат от инвестиций в технологии (ROI);

· уточнения понимания и формализации описания бизнес-процессов путем формального их моделирования.

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

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

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

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

Рис. 3.12. Синхронизация потребностей бизнеса и возможностей ИТ

 

Одной из концепций, ключевой для понимания роли архитектуры предприятия, является концепция расширенной цепочки добавочной стоимости (value chain) ключевых бизнес-процессов [3.18]. Идея "цепочки добавочной стоимости" привлекла к себе внимание в середине 1980-х годов, когда Майкл Портер (Michael E. Porter) из Гарвардской бизнес-школы опубликовал книгу "Конкурентное Преимущество" (Competitive Advantage, 1985). Большое количество специалистов в области корпоративной стратегии и управления активно используют на практике предложенные Портером модели, такие как "модель пяти факторов влияния", для анализа конкурентной среды и связанных с этим и возможностей угроз.

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

Рис. 3.13. Связь требований бизнеса и различных областей архитектуры ИТ

 

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

Рис. 3.14. Бизнес-процессы и обеспечивающие информационные системы в рамках цепочек создания добавочной стоимости

 

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

При этом исследования показывают, что огромное количество ценной информации может быть получено без выполнения анализа бизнес-процессов с "парализующей" степенью детализации. Иными словами, применимо правило "80/20". Достаточно знать восемьдесят процентов необходимых деталей о процессах, что может быть получено двадцатью процентами возможных усилий на анализ этих процессов. Это же правило применимо и к архитектуре предприятия в целом.

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

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