Заключение
Заключительные замечания:"Архитектура предприятия мертва! Да здравствует архитектура предприятия!"
Ну что ж. Эта позиция критиков архитектурных подходов понятна, заслуживает внимания, а главное, извлечения положительных уроков. Попробуем это сделать и мы, сославшись на мнение авторитетов [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].
"Старая" архитектура ИТ | "Новая" архитектура предприятия | |
---|---|---|
Стандарты | "Один размер" подходит на все случаи жизни (узкий набор стандартов, применяемых всегда) | Ограниченный список стандартов, с возможностью выбора и рекомендациями по применению |
Приоритеты/Цели | Уменьшение затрат. Уменьшение сложности | Уменьшение времени внедрения систем. Уменьшение сложности плюс источник экспертизы |
Основная область внимания | Инфраструктура | Прикладные системы |
Исследования | Продолжительный анализ для выбора стандартов | Быстрый процесс анализа, постоянные обновления для обеспечения текущих потребностей |
Средства накопления знаний | Документация с описанием архитектуры | Web-сайты, содержащие информацию в форме руководств по использованию; архитектурные шаблоны; модели и примеры; программные продукты управления архитектурой |
Консультирование | В ограниченной форме | Большее внимание консультированию по вопросам архитектуры |
Структуры и процессы управления | "Полицейские" функции, недопущение исключений | Помощь в процессе проектирования систем, связь с другими процессами планирования на предприятии |
Архитектура предприятия сегодня нужна более, чем когда-либо. В разные времена требуются различные методики и подходы, для того чтобы эффективно использовать новые тенденции и технологии. И Архитектура предприятия как дисциплина, которая имеет отношение к процессам планирования, является просто необходимостью.
Так что, "Архитектура предприятия мертва! Да здравствует Архитектура предприятия!"