Заключение

Объединяем концепции и процессы

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

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

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

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

Наконец, все это требует реализации целого ряда управленческих процессов, связанных с информационными технологиями: процессов управления и контроля ИТ в целом и архитектуры, в частности, процессов и методик принятия решений об инвестициях в ИТ-проекты, управления программами и проектами. Все эти концепции и процессы отражены на рис. 9.1.

Большинство этих тем нашло отражение в соответствующих лекциях курса.

Альтернативные взгляды на архитектуру предприятия

Авторы курса искренне верят, что идеи, связанные с разработкой и реализацией архитектуры предприятия, могут принести существенную пользу как в организации работы департаментов информационных технологий, так и в организации их эффективного взаимодействия с бизнес-подразделениями. Однако нам хотелось бы быть до конца честными перед читателями и изложить критические и альтернативные взгляды на теорию и практику Архитектуры предприятия, которые в достаточно сконцентрированном виде были изложены, в частности, в статье [10.1], название которой на русский язык можно перевести как "Архитектура предприятия, покойся с миром!"

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

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

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

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

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

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

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

Короче, "Мир праху твоему, архитектура предприятия!".

Заключительные замечания:"Архитектура предприятия мертва! Да здравствует архитектура предприятия!"

Ну что ж. Эта позиция критиков архитектурных подходов понятна, заслуживает внимания, а главное, извлечения положительных уроков. Попробуем это сделать и мы, сославшись на мнение авторитетов [10.2].

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

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

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

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

Мы уже говорили, что в основе концепций Архитектуры предприятия лежат работы Захмана, которые, в свою очередь, основаны на методиках IBM-планирования бизнес-систем (BSP – Business System Planning), разработанных в 70-х годах прошлого века. Они создавались для того, чтобы обеспечить механизмы оптимального инвестирования в ИТ-системы и разрабатывать оптимальные стратегии сопровождения и эксплуатации систем. Эти методики, в том числе, помогали организациям формализовывать и стандартизировать процессы еще до этапа их автоматизации. Мы все знаем, что когда автоматизированы плохие процессы, порядок вещей становится только хуже: все будет работать так же плохо, но только с большей скоростью и с еще большим отрицательным эффектом.

До начала 1990-х годов в своем первозданном виде Архитектура предприятия была адекватным подходом. Однако по мере того как развивалось программное обеспечение, по мере того как коммерческое программное обеспечение становилось независимой отраслью деятельности, аппаратное обеспечение также начинало становиться все более стандартным. На смену философии "никто никогда не был уволен за то, что он покупает IBM" пришла философия "программное обеспечение определяет выбор платформы".Эта смена философии привела к смене подходов по разработке Архитектуры предприятия. Разработка моделей данных в виде диаграмм "сущность-связи" в нормальных формах для всей информации, которую предприятие будет использовать в будущем, перестало быть адекватным подходом. Почему? В 1990-х годах появились корпоративные программные продукты, каждый со своими моделями данных: например, системы управления ресурсами предприятия (ERP), системы управления поставками (SCM), системы управления отношениями с заказчиками (CRM). Все, кто добровольно отказался в этих условиях от планирования через разработку Архитектуры предприятия, в полной мере испытали проблемы одновременного использования нескольких корпоративных систем внутри предприятия, имеющих перекрывающийся функционал и пересекающиеся наборы данных.

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

Мы уже говорили, ссылаясь на данные аналитических компаний, таких как META Group, что организации, которые используют стандарты в рамках единой Архитектуры предприятия, нередко достигают 30% экономии затрат на реализацию своих ИТ-систем.

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

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

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

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

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

Эти отличия между "старыми" и "новыми" представлениями об архитектуре приведены в таблице 9.1 ниже [10.3].

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

Так что, "Архитектура предприятия мертва! Да здравствует Архитектура предприятия!"