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

Вообще говоря, при разработке и использовании архитектуры предприятия, конечно же, целесообразно придерживаться какой-либо одной методики, которая обеспечивала бы единство в подходах и соответствующие наборы инструментов для описания архитектуры. Мы кратко рассмотрим наиболее известные методики в "Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF" и "NASCIO. Модели "4+1" и SAM. Методики Microsoft и другие. Выбор "оптимальной" методики" . Здесь же мы детализируем наше общее представление о понятии " архитектура предприятия".

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

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

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

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

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

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

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

Пользователями архитектуры предприятия является достаточно обширная аудитория специалистов и руководителей:

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

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

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

Итак, прежде чем продолжить, приведем еще одно определение архитектуры предприятия, которое дано на сайте www.geao.org "Всемирной Организации Корпоративной Архитектуры" (GEAO – Global Enterprise Architecture Organization):

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

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

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

Мы уже отмечали, что движущей силой архитектуры предприятия является целостное видение, пронизывающее внутриорганизационные границы. Представленная на рис. 4.1 схема, предложенная GEAO, иллюстрирует различные уровни абстракции, связанные с описанием предприятия. Отметим, что в рамках одной организации имеется только одна архитектура предприятия, но при этом на уровне отдельных систем может существовать большое количество архитектур уровня решений (solution architecture ). Архитектура предприятия покрывает как аспекты, связанные с бизнесом, так и аспекты, связанные с ИТ, а также процессы развития, эволюции архитектуры и структуры управления и контроля за этими процессами ( governance ), которые обеспечивают переход от текущего состояния архитектуры в будущее желаемое состояние.

Начал работать с одной компанией на тему архитектуры предприятия (Enterprise Architecture) и решил скорректировать своё представление об EA, сделать его понятней и проще. Обычно, датой рождения EA считают публикацию John A. Zachman «A Framework for Information Systems Architecture» 1987 года, хотя сам термин появлялся и в боле ранних работах. Не смотря на то, что архитектура предприятия вещь довольно молодая, она успела уже подпортить себе репутацию. Как и любая другая архитектура, архитектура предприятия не имеет точного определения(см., например, 10 Definitions of Enterprise Architecture), но зато имеет большое число неудачных проектов (см. Gartner Identifies Ten Enterprise Architecture Pitfalls или 8 Reasons Enterprise Architecture Programs Fail). Обычно, после завершения проекта по разработке архитектуры предприятия можно услышать такую фразу: «Мы нарисовали все необходимые картинки, но не имеем ни малейшего представления как извлечь из этого хоть какую-то пользу ». Поэтому, давайте проговорим все с самого начала.

А начнем мы издалека. Существуют две точки зрения на полезность информационных технологий. Согласно первой точке зрения информационные технологии позволяют повысить производительность труда, т.е. люди буду работать эффективнее, если их деятельность автоматизирована. Существует и противоположная точка зрения, выраженная, например, в таких книжках как «Блеск и нищета информационных технологий. Почему ИТ не являются конкурентным преимуществом » Николаса Дж. Карра или «Чего хочет бизнес от IT » Терри Уайта. Удивительно то, что обе эти точки зрения правильные. Но давайте сузим круг наших рассуждений и будем говорить не про информационные технологии в целом, а только о бизнес-приложениях, т.е. системах, автоматизирующих бизнес-процессы организации. Сначала разработка и внедрение таких систем приносит ощутимый эффект. Когда разные сотрудники начинают отражать схожие операции в единой базе данных, доступной через сеть с разных рабочих мест, взаимодействовать друг с другом посредством таких решений, специализироваться в определенных функциях производительность их труда растет. Это намного лучше, чем звонить друг другу по телефону или обмениваться эмоционально окрашенными сообщениями по электронной почте. Поэтому, автоматизации начинают подвергаться разные другие процессы, может быть не столь частые и не столь нужные. Эффективность такой автоматизации не столь высока. Висящие низко яблоки уже сорваны и приходится изобретать более изощренные способы достижения результата. В какой-то момент издержки применения бизнес-приложений становятся больше, чем получаемая от их использования выгода, но остановить разогнавшийся паровоз уже нельзя. Причина наличия такого порога в органической сложности информационных систем (IT Complexity). По сути, в какой-то момент мы просто запутываемся в том, что делаем, а информационные системы помогают нам запутаться еще сильней. Архитектура(предприятия) — это просто способ контролировать присущую системам сложность, держать в голове более-менее адекватную картинку, пока еще позволяющую этой сложностью управлять.

Следующая проблема заключается в том, что такую картинку нельзя подготовить впрок. (В этом месте архитекторы наговорят вам много заумных слов о различных точках зрения, представления, стейкхолдерах и консернах). Поэтому, отвечать на вопрос «Зачем мы делаем архитектуру предприятия?» надо с самого начала. Я позволю себе выделить три наиболее частых варианта ответа:

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

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

В первом случаем нам надо сделать из Стратегии –> План . Речь идет, в основном, о бизнес-стратегии. Выглядит она, обычно, как набор некоторых дельт между тем, что есть и тем чего хочется, выраженных в довольно простых показателях: доля рынка по выручке, объем клиентской базы и пр. В общем, сами знаете, стратегия – это документ про завтрашних ёжиков, которыми предстоит стать сегодняшним мышкам. О том, что следует делать в этом случае, я напишу в отдельном сообщении, а пока несколько слов о том, как организовать такой процесс. На мой взгляд, организационная форма разработки архитектуры предприятия это проект, продолжительностью 8-16 недель. Методология – TOGAF ADM и т.п. Ресурсы следует привлекать, в основном, внутренние. Результатами проекта являются: дорожная карта, список организационных и процессных изменений, риски, предложения по контролю и управлению движением в заданном направлении. В общем, все, что делается в традиционных проектах на фазе планирования и называется красивым словом мастер-план . Про команду такого проекта, набор активностей и артефактов – то же в одном из следующих сообщений.

Вариант номер 2: Change management . Вместо стратегии есть набор различных целей у различных бизнес-заказчиков. Одни должны сократить затраты, другие — время вывода на рынок новых продуктов и услуг, а третьим следует повысить степень удовлетворенности клиентов (см. Об архитектуре предприятия парой фраз). Все заказчики люди уважаемые и каждому надо помочь. Но complexity уже выросло и как помочь всем одновременно мы не понимаем. Простой и неправильный способ выстроить всех в одну очередь с красивым названием, например «Единый лист приоритетов», а способ распределения задач по информационным системам — «Свободная касса!» — кто сумеет сделать быстрее и дешевле, тому и поручим. Правильное решение – многофакторная классификация запросов, проще говоря – таксономия. Методология – в стиле Захмана. Организация – создание функционального подразделения. В предыдущей заметке Бизнес-аналитики – друзья, соседи или дальние родственники? я написал, что с появлением и принятием третьей версии BABOK эту работу смогут делать бизнес-аналитики. Но пока что не могут. На текущий момент бизнес-аналитики умеют отвечать на вопрос «Что надо сделать?», а архитекторы решений на вопрос «Как это сделать?». Здесь же требуется ответ на вопрос «Зачем?», как это изменение связано с существующими продуктами и процессами, другими изменениями, приложениями.

Ну и напоследок ситуация, когда complexity уже победила и осознание этого есть у руководителей организации. Про те самые картинки , которых нет, когда они нужны, чтоб быстро разобраться в противоречивой проблеме и которые лежат совершенно никчемным грузом все остальное время. Эта ситуация – разговор об архитектурном репозитории. Картинки с описанием архитектуры может быть где-то и есть, но если их нельзя достать в течении минуты-другой, то руководитель, да и любой менеджер, не станет это делать сам, а попросит достать картинку кого-то другого («Позвать сюда архитектора!»). Если человек не работает с приложением хотя бы раз в 1-2 недели, то он не станет этого делать вообще. Если у разработчика информационной системы нет простых, понятных и готовых к использованию APIs для получения типов клиентов, списка филиалов, функциональной орг.структуры и пр., то он обязательно нафигачит в своей информационной системе еще одну табличку, в которую заставит пользователей вводить данные этих справочников заново. Мне неизвестен ни один EA Tool одинаково пригодный и для демонстрации красивых картинок топ-менеджерам и одновременно обладающий врожденной интеоперабильностью для интеграции в реальные бизнес-приложения. Надеюсь, что такие, рано или поздно, появятся. И тогда вариант номер три превратиться в простой проект по внедрению информационной системы и последующему её использованию и развитию.

Продолжение (истории про архитектуру предприятия) следует!

Информационные технологии и управление предприятием Баронов Владимир Владимирович

Зачем требуется понятие архитектуры

Использование понятия «архитектура предприятия» позволяет установить связь между бизнесом предприятия и параметрами информационной системы – функциями системы и интероперабельностью данных.

Основными предпосылками к использованию понятия архитектуры являются стандарты и унификация методов сбора данных

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

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

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

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

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

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

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

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

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

Приведение предприятия в соответствие с намерениями – реальное обеспечение того, что преобразованное предприятие будет соответствовать исходным требованиям;

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

Облегчение управления изменениями в любых аспектах предприятия:

– конвергенция – использование стандартных информационных технологий;

– улучшение связи между основными подразделениями и подразделениями информационных технологий в пределах всего предприятия на основе использования стандартизированного словаря;

– наглядное представление предприятия, которое помогает связывать и описывать большие системы и облегчает управление в сложных средах;

– ориентация на стратегическое использование современных технологий для управления большими потоками информации;

Улучшение согласованности, точности, своевременности, целостности, качества, пригодности, доступности и возможностей совместного использования общей информации;

Совершенствование процессов планирования капиталовложений и инвестиционного управления;

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

Достижение экономии на основе совместного использования услуг в масштабах всего предприятия;

Упрощенная интеграция наследуемых, перемещаемых и новых систем.