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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

Характерной чертой современного бизнеса является исключительно высокая скорость происходящих изменений в окружающей среде. Практически ни в одной области бизнеса компании не могут чувствовать себя абсолютно спокойно и делать долгосрочные прогнозы, основанные на стабильности и неизменности ситуации. Напротив, постоянные изменения становятся скорее нормой, чем исключением. Поэтому, как уже отмечалось ранее в лекцииях 1 и 2, компании должны уметь приспосабливаться к этим условиям и иметь возможность адекватно реагировать на изменение условий бизнеса. Большой интерес сейчас представляет создание модели так называемой адаптивной организации, которая должна содержать внутренние механизмы для изменения в соответствии с требованиями внешнего окружения. Этой теме, в частности, посвящена книга С. Хэкела.

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