Процесс разработки архитектур: управление и контроль, Gap-анализ, внедрение

Организационные структуры, связанные с разработкой архитектуры

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

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

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

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

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

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

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

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

Таким образом, постоянная работа непосредственно над архитектурой с организационной точки зрения ведется как бы на трех уровнях:

С практической точки зрения, архитектура реализуется постепенно и поступательно через выполнение отдельных проектов. Типичная ситуация выглядит так:

Обеспечение соответствия проектов архитектуре

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

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

Для этого можно применить подход, предложенный в публикациях Giga Group [6.14], где предлагается модель, которая обеспечивает классификацию архитектурных решений в соответствии со стратегическим позиционированием каждого решения так, как это показано на рис. 11.3.

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

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

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

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

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

Более развернутые рекомендации по контролю соответствия содержатся в модели TOGAF, где описаны два основных процесса:

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

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

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

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

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

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

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

Оценка затрат на разработку и сопровождение архитектуры предприятия

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

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

На самом деле, на этот счет отсутствуют детальные и точные данные. По оценке Gartner [6.16], в большинстве организаций вопросами разработки архитектуры и стратегического планирования в области ИТ занимаются обычно 2-4% персонала ИТ-служб. Кроме затрат на персонал, дополнительные расходы связаны с приобретением средств моделирования и созданием репозитория для хранения артефактов (документов, моделей и пр.), описывающих архитектуру предприятия.

Во-первых, необходимо учесть размеры первоначальных затрат, связанных с инициированием архитектурного процесса: обучение, подготовка обоснования необходимости создания архитектуры предприятия, создание структур управления и контроля. Эти траты вряд ли будут превышать примерно 50% последующих ежегодных затрат на поддержку архитектуры.

Текущие затраты на сопровождение архитектуры включают:

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

Правительство США планировало инвестировать в 2004 году суммарно около одного миллиарда долларов в различные инициативы, связанные с архитектурой информационных технологий [6.17]! При этом надо учитывать, что общие затраты на информационные технологии в государственном секторе США составляют примерно 60 млрд. долларов в год.

Данные по отдельным ведомствам, полученные методом опроса, сами по себе очень сильно отличаются от агентства к агентству. Так, затраты на разработку архитектуры находятся в диапазоне примерно от $100 тыс. для таких относительно небольших агентств, как Администрация Международной Торговли (International Trade Administration) и Администрация Экономического Развития (Economic Development Administration) соответственно, и до $18-20 млн. для таких крупных агентств с очень сложной ИТ-инфраструктурой и широким спектром прикладных систем, как Министерство по налогам (Internal Revenue Service) и Национальное Агентство по Картографии (National Imagery and Mapping Agency).

Соответственно, ежегодные затраты на поддержание архитектуры составляют порядка 10% от стоимости разработки, т.е. примерно от $10 тыс. до $1,5 млн. Можно попробовать "спроецировать" эти суммы на российскую действительность с учетом разницы в стоимости оплаты труда ИТ-персонала в двух странах.

Gap-анализ (анализ несоответствий) и модель развития элементов ИТ-архитектуры

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

Процесс анализа на несоответствия включает следующие шаги:

Для категоризации несоответствий можно, в частности, использовать матрицу, показанную в табл. 11.1.

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

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

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

Процедурные несоответствия – это несоответствия между существующими и желаемыми методами управления, стратегиями сорсинга, процессами эксплуатации ИТ-сервисов и организационными процедурами.

Таким образом, условно можно сказать, что существует два типа несоответствий:

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

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

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

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

Аспект планирования и управления включает:

Аспект стандартизации включает:

Оценка перспективности развития проводится с учетом:

Такая модель в области системного программного обеспечения для некоторой гипотетической компании может иметь вид, показанный в табл. 11.3.

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

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

Творческий характер архитектурного процесса

Итак, для описания архитектур существует множество различных методик и вариантов, отличающихся группировкой рассматриваемых понятий. Для упорядочения выполняемых работ предложены специальные методы – например, описанный выше TOGAF ADM. Казалось бы, что разработка архитектуры в этих условиях будет являться достаточно простым, повторяемым и рутинным процессом. На самом деле, в этих рассуждениях опущено одно очень важное звено: организации и их системы уникальны, и процесс проектирования архитектуры по необходимости должен являться творческим. Реально каждый новый проект представляет собой (в идеале) достижение компромисса между применением стандартных шаблонов и учетом специфических особенностей. Этот процесс формализуется труднее всего. Но здесь есть и положительная сторона – многие творческие приемы, которые были разработаны и успешно применены в смежных дисциплинах, таких как системное проектирование или разработка программного обеспечения, могут быть применены и для развития архитектуры предприятия в целом и, в частности, ИТ-архитектуры.

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

В условиях быстро изменяющейся внешней среды изменяются и сами методы разработки: все большее значение приобретают гибкие, динамичные (agile) подходы, вплоть до методов так называемого "экстремального (XP) программирования".

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

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

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

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

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

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

Например, при реализации системы управления документами одними из важнейших параметров будут являться число пользователей и число документов. Соответствующая диаграмма из книги [6.20] показывает в этих координатах характерные области для таких различных систем, как промышленные электронные архивы (пример – DB2 Content Manager от IBM), системы управления документами Documentum (EMC), Дело (ЭОС) или БОСС-Референт (АйТи), настольные приложения или поисковые системы Интернет.

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

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

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

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

Интересным "нестандартным" примером из практики авторов явилось проведение динамического моделирования архитектуры комплексной информационной системы Госкомстата России (ныне Федеральная служба государственной статистики) с использованием универсальных средств моделирования Rethink и среды выполнения G2 компании Gensys. Данная информационная система строится по трехуровневому принципу и включает центральный узел, территориальные центры и районные (городские) отделения. Задачей системы является сбор и обработка большого количества информации по более чем 500 задачам статистического наблюдения от нескольких миллионов предприятий и выбранных для мониторинга домохозяйств. Задачей моделирования являлся выбор оптимального (с точки зрения соблюдения заданных сроков обработки при общей минимальной стоимости системы) числа и мест размещения территориальных центров обработки данных в стране, а также конфигурации вычислительных средств в этих центрах, с учетом существенно неравномерного распределения субъектов наблюдения по регионам, сезонных колебаний объемов обрабатываемой информации, наличия каналов связи. Исходная задача имела около 107 параметров, которые после ряда упрощений были сведены примерно к 102 параметрам, однако и в такой постановке задача не поддавалась аналитическому решению. Для решения упрощенной задачи выбора оптимальной конфигурации была создана модель [6.21] в среде G2/Rethink, которая позволила получить оценки для наиболее важных метрик, характеризующих параметры работы системы в условиях заданной нагрузки и с учетом влияния дополнительных случайных факторов.

Как обеспечить внедрение результатов проекта разработки архитектуры

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

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

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

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

Различия в ожидании преимуществ от архитектуры

	Высшее руководство	Руководители бизнес-подразделений	Участники разработки приложений	Специалисты по эксплуатации ИТ
Повышение способности к взаимодействию
Стоимость владения ИС
Гибкость и масштабируемость
Быстрота разработки
Соответствие бизнесу
Эффективное использование ресурсов
Безопасность
Риск
Инновации в бизнесе

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

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

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

Один хороший метод в объяснении важности архитектуры ИТ для бизнес-руководителей и неспециалистов в области ИТ сводится к двум темам [6.23]:

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

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

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

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

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

Более подробно эти аспекты рассматриваются в [6.5]. В частности, там выделяются группы внутри ИТ-службы, как показано в табл. 11.5.

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

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

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