Процесс Управления Архитектурной Практикой

Архитектурная практика представляет из себя практику внедрения архитектурного проекта в организации. Архитектурная практика состоит из четырех ключевых элементов:

•Люди. Они основа любой деятельности в компании. Если люди не знают, не умеют, не используют, не участвуют, не делают, не хотят, то все остальное бесполезно. Забыли про людей – забудьте про результаты.

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

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

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

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

•залезают в дебри теорий и исследований;

•выполняют бесполезную работу;

•долго готовятся к выполнению работы;

•изобретают велосипед;

•«оптимизируют» свою работу вместо её выполнения;

•излишне теоретизируют;

•ищут ответственных и виноватых;

•считают себя самыми умными;

•избегают неприятной работы.

Подход к управлению архитектурной практикой состоит из шести основных элементов:

Методология — это основной элемент подхода. Он определяет процессы компании для разработки, обновления и реализации Архитектуры Предприятия. Роли и их обязанности.

Артефакты — набор, шаблоны и правила заполнения документов, таблиц, схем, при помощи которых описана Архитектура Предприятия.

Стандарты — это стандарты (законы, правила) ведения бизнеса и ИТ, которые использует компания в своей работе. Это могут быть международные стандарты, российские стандарты, стандарты отрасли, региона, компании.

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

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

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

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

Ключевые документы и шаблоны методологии TOGAF

Для внедрения методологии TOGAF возникает вопрос какой минимальный набор документов необходим для ведения архитектурного проекта? Лишние документы – лишние затраты времени и денег. По исходя из собственного опыта и теории (при подготовке к сертификации), минимальный «джентельменский набор» может состоять из восьми документов:

Основы методологии (Templates, Business Principles, Goals, Drivers). Необходим для понимания миссию, цели, стратегию компании. Зафиксировать бизнес принципы. Шаблон «TOGAF 9 Templates, Business Principles, Goals, Drivers.doc»

Архитектурные принципы (Architecture Principles) – это правила, которыми руководствуются в работе над архитектурой. На их основе принимают архитектурные решения. Принципы нужно сформулировать на основе примеров из TOGAF. Использование принципов при работе над архитектурой доказало свою эффективность. Шаблон – «TOGAF 9 Template Architecture Principles.doc»

Видение архитектуры (Architecture Vision) – это высокоуровневое описание желательного конечного продукта архитектурного проекта. То есть это те результаты, которых нужно достичь. Описание решения тех проблем и задач, ради которых стартуют проект. Этот документ важен для взаимодействия со спонсором проекта и другими заинтересованными лицами. Шаблон – «TOGAF 9 Template Architecture Vision.doc»

Устав проекта (Statement of Architecture Work) – соглашение между спонсором и проектной командой о выполнении работ. В него включают все рамки, ограничения, предположения, сроки, бюджет, правила проекта. В нем конкретно назначают менеджера проекта и прописывают его права и обязанности. Сюда же включают как приложение видение архитектуры как описание рамок проекта. Шаблон – «TOGAF 9 Template Statement of Architecture Work.doc»

Описание архитектуры (Architecture Definition) – это представление текущей и целевой архитектуры. Он охватывает каждый из архитектурных доменов (бизнес, данные, приложения, технологии). А также анализ расхождений между текущим и будущим состоянием. Шаблон – «TOGAF 9 Template Architecture Definition.doc»

Спецификация требований к архитектуре (Architecture Requirements Specification) – документ, в котором собраны все требования, ограничения, предположения, критерии достижения. Шаблон – «TOGAF 9 Template Architecture Requirements Specification.doc»

Переходная архитектура (Transition Architecture) – Реализация целевой архитектуры проходит в несколько этапов. Каждое промежуточное состояние должно быть работоспособно и давать компании большую ценность. В этом документе сгруппированы проекты по каждому из таких этапов. Шаблон – «TOGAF 9 Template Transition Architecture.doc»

План реализации и миграции (Implementation and Migration Plan) – это сводный план реализации проектов, направленных на достижение целевой архитектуры. В него также включают выгоды, рамки, сроки, стоимость, риски, контрольные точки проектов. Шаблон – «TOGAF 9 Template Implementation and Migration Plan.doc»

Такой набор документов можно сделать максимально быстро и без больших затрат. Если предполагается воспользоваться услугами третьих сторон, то рекомендую включить ещё один документ – архитектурный контракт. Это соглашение между архитекторами и исполнителями ИТ проекта. Шаблон – «TOGAF 9 Template – Architecture Contract.doc» При приемке проекта вам будет легче получить нужный результат, если вы о нем заранее договорились.

Подходы к построению ИТ Стратегии

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

Первый шаг – оцениваем текущее состояние Архитектуры Предприятия (Baseline Architecture). Концентрируем внимание на вопросах бизнеса (Business Architecture) и начинаем с общих высокоуровневых вопросов. На данном этапе желательно провести интервью или просто побеседовать с руководством компании, топ менеджерами. Для данной задачи хорошо бы было участие двух специалистов уровня экспертов. Причем один в области управления, консалтинга или аудита, с хорошими аналитическими способностями и пониманием бизнес составляющей (ИТ Директор, Chief Information Officer CIO), а второй, эксперт в области информационных технологий (ИТ Архитектор, Chief Technology Officer CTO). Их главная задача – слушать. Ключевые вопросы, которые помогут удерживать направление беседы в бизнес сфере, сводятся к определению следующих составляющих:

•Основной вид деятельности организации

•Организационная структура

•Особенности ведения бизнеса

•Миссия и видения организации

•Цели и задачи

•Текущие проблемы организации

•Организация и оценка текущего состояние ИТ по мнению руководства

Следующий шаг – формируем видение Целевой Архитектуры Предприятия (Target Architecture). Для этого, задавая наводящие вопросы, пытаемся определить видение руководства, цели бизнеса, ожидания и чаяния. Видение будущего ИТ, его роли, вовлеченность в бизнес и т п. Важный момент данного этапа общения – Не прерывайте их!!! Дайте им высказаться, помечтать. Даже если их фантазии будут время от времени противоречить друг другу, и здравому смыслу. Ваша задача – собрать как можно больше информации. Руководство организации является заказчиком. А как говорится: «… кто музыку заказывает, тот ее и танцует…». Запомните, а затем запишите и проанализируйте всю информацию.

По окончанию первых двух шагов, у нас будет воздушный замок высокоуровневой «Архитектуры Бизнеса» для «Текущей» и «Целевой» Архитектуры Предприятия конкретной организации:

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

Текущая Архитектура

•Архитектура Бизнеса

•Архитектура сегментов

•Информационные Системы

•Техническая Архитектура

План Перехода

•Наброски и идеи

Целевая Архитектура

•Архитектура Бизнеса

•Архитектура сегментов

•Информационные Системы

•Техническая Архитектура

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

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

•корпоративная стратегия (на уровне корпорации, холдинга),

•бизнес-стратегия (на уровне отдельной бизнес-единицы)

•функциональные стратегии (на уровне отдельных функциональных направлений в бизнес-единице).

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

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

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

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

Можно предложить следующие информационные разделы для ИТ-стратегии:

•Цели для ИТ в привязке к бизнес-целям организации.

•Направления развития ИТ для достижения обозначенных целей.

•Проекты, которые должны быть реализованы в рамках каждого направления.

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

•Основные этапы по каждому проекту (краткое описание результатов, сроки, стоимость).

•Набор KPI для мониторинга развития ИТ и достижения соответствующих целей.

•Бюджеты ИТ-проектов, направлений и общий бюджет ИТ.

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

Построении ИТ Архитектуры и ИТ Стратегии в организации можно графически представить в виде диаграммы.

Для понимания проблем бизнеса и перевод их на язык ИТ можно воспользоваться методикой «дерево проблем – решений». Как видно из диаграммы, бизнес формулирует свои проблемы на языке бизнеса. Задача ИТ директора перевести язык бизнеса на технический язык, для дальнейшего формирования ИТ проектов и постановки задач сотрудникам ИТ департамента. Для того, чтобы бизнес и ИТ понимали, что необходимо требовать друг от друга, необходимо определить критерии достижения целей и задач, а также метрики их измерения.

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

Для чего необходим департамент ИТ (миссия департамента). Миссия ИТ должна отвечать следующим параметрам:

•Соответствие миссии организации

•Соответствовать внутренним и внешним бизнес требованием организации