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

Управление и контроль архитектурного процесса (governance)

Методы управления и контроля

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

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

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

Вообще говоря, следует отличать понятие управления и контроля архитектурного процесса от более широкого понятия управления и контроля использования ИТ на предприятии в целом.

Мы ранее говорили о том, что разработка архитектуры строится на основе двух групп механизмов. Первая группа механизмов – это архитектурные принципы: условно говоря, "неявные" (implicit – по аналогии с принципами управления знаниями) механизмы. Вторая группа механизмов описания архитектуры включает определение формальных стандартов, моделей и требований, – "явные" (explicit) инструменты и механизмы.

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

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

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

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

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

• Публикации и распространение информации и документов описания архитектуры. Подход, который можно охарактеризовать так: "Подайте пример, и люди сами за вами потянутся". На самом деле, публикация архитектурных документов является очень важным аспектом всего процесса управления архитектурой, но сам по себе этот инструмент не будет работать без других механизмов. С разработкой и реализацией архитектуры предприятия связаны интересы большого количества сторон, поэтому информация об архитектуре должна распространяться внутри организации на различных уровнях, в том числе с использованием визуальных, графических средств представления или специализированных языков. Для высшего руководства архитектура должна демонстрировать, как она обеспечивает достижение бизнес-целей и какие преимущества будут получены. Областью интереса бизнес-пользователей являются их специфические предметные области и функциональные потребности. Руководители в области ИТ и технический персонал больше сфокусированы на технических компонентах, включая то, как впоследствии будет обеспечиваться поддержка и сопровождение разрабатываемых решений. Архитекторов отдельных проектов волнуют такие вопросы, как стандарты, шаблоны и правила, пригодные для повторного использования либо накладывающие ограничения на дизайн отдельных решений. Публикуя информацию об архитектуре, нужно стремиться удовлетворить все перечисленные категории заинтересованных сторон. Более того, чем более открытой является эта информация внутри предприятия (за исключением, возможно, определенных аспектов архитектуры безопасности), тем больший эффект это принесет.
• Создание формальных структур, таких как Совет по архитектуре. На регулярных заседаниях таких формальных структур должны рассматриваться, в частности, архитектурные вопросы новых систем и инициатив. Эти структуры должны утверждать или отвергать проекты, в зависимости от того, насколько соблюдены принятые в архитектуре принципы, модели и стандарты. Большим преимуществом является ситуация, когда методики разработки систем и процессов управления проектами широко известны и используются в организации и когда рассмотрение проекта Советом по архитектуре является стандартным этапом процесса. Конечно, возможность этого комитета говорить "да" или "нет" по поводу проектов является важной, но даже сам факт наличия формального процесса рассмотрения проектов на соответствие архитектуре имеет колоссальный положительный эффект. Недостатками этого метода управления могут оказаться: дополнительный уровень бюрократии, отсутствие у комитета реальных рычагов изменения проектировочных решений, возможность задержек в рассмотрении вопросов в ситуации, когда требуется быстрое принятие решений.
• Контроль процесса закупок. Предполагается такое выстраивание процесса, когда закупка продуктов и технологий, соответствующих архитектуре, выполняется легко и просто, а покупка нестандартных с точки зрения принятой архитектуры продуктов существенно затруднена. Обеспечение связи между процессом закупок информационных технологий и стандартов архитектуры является ключевым способом институализации архитектуры и ее "внедрения" в культуру деятельности предприятия.
• Обеспечение консультирования по вопросам архитектуры. Это наиболее эффективный, имеющий минимальный уровень бюрократии процесс управления архитектурой. Он состоит в использовании ресурсов внутренних консультантов по вопросам архитектуры на самых ранних этапах проектов; они дают рекомендации, касающиеся выбора технологий и общих принципов проектирования системы. В отличие от формальных методов контроля, рассмотрения на комитетах и т.д., модель, предполагающая консультирование, является проактивной и упреждающей. Конечно, и у этого способа есть свои ограничения, поскольку есть опасность, что ограниченные ресурсы группы, отвечающей за разработку архитектуры, станут чрезмерно распыляться на работу по отдельным проектам.

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

Рис. 11.1. Элементы управления и контроля архитектуры на различных этапах ИТ-проектов

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

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

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

Интересными являются данные о том, какие механизмы – жестко контролируемое выполнение правил или информирование и общие рекомендации – организации чаще применяют на практике для обеспечения соответствия технических решений архитектуре. В частности, опрос, проведенный в 2003 году компанией Gartner среди финансовых организаций, показал, что примерно 50-60% организаций реализуют механизмы жесткого контроля за соблюдением предписаний архитектуры. Примерно 20-25% используют такие механизмы как общие рекомендации, при этом подразделения несут дополнительные затраты, связанные с несоответствием проектов утвержденной архитектуре. Только в 15-25% организаций архитектура носит рекомендательный характер, и невыполнение рекомендаций не имеет никаких явных организационных последствий [6.13].

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

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