Процесс разработки архитектур: цели и задачи, общая схема

С чего начать?

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

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

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

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

Основная сложность обоснования необходимости архитектурного проекта и выделения соответствующих инвестиций связана с тем, что прогнозируемые результаты обычно предполагают косвенное улучшение бизнеса организации, то есть являются, как правило, качественными и редко могут быть связаны с конкретными финансовыми выгодами. Даже в том случае, когда бизнес-показатели типа "увеличение стоимости акций компании" или "доля на рынке" измеримы, конкретные связи между ними и проведенным реформированием архитектуры предприятия обычно бывают трудно доказуемы. Доля таких компаний не превышает величины порядка 5%. При этом аналитики МЕТА отмечают, что в настоящее время более чем в 70% компаний ИТ-служба все еще является центром затрат, а более 90% ИТ-служб не имеют согласованных с бизнес-руководством финансовых моделей, позволяющих количественно измерить эффект от внедрения ИТ для бизнеса.

С точки зрения обоснования цифр экономии практически невозможно дать какие-то общие, применимые на все случаи, оценки затрат, связанных с отсутствием архитектуры ИТ. Это зависит от уникальности ситуации в каждой конкретной организации. Экономия может быть достигнута, в частности, за счет сокращения расходов, связанных с повторным использованием оборудования или программного обеспечения, за счет сокращения времени разработки, оптимизации расходов на ведение проектов, снижения стоимости технической поддержки, приобретения новых активов или экономии за счет более простой адаптируемости системы, построенной на базе единой архитектуры, к изменению требований бизнеса. Последняя составляющая выгоды обычно становится заметной при сравнении затраченных усилий, средств и времени для проведения изменений в различных подразделениях организации с отличающимися исходными архитектурами. В целом, по данным опроса META, снижение величины расходов на ИТ в расчете на одного сотрудника в случае реализации единой корпоративной архитектуры может достигать величины порядка 30%. По оценке Gartner отсутствие архитектуры приводит к 12-18% дополнительных затрат, связанных только с эксплуатацией ИТ-инфраструктуры.

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

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

Инвестиции в архитектуру предприятия, эффект от использования которой может быть не столь очевиден в течение трех-пяти лет, требуют иных мер оценки эффективности. Возможной стратегической альтернативой является величина "Возврата на основные фонды" (ROA – Return on Assets), которая будет стимулировать компанию оценивать архитектуру ИТ с точки зрения повышения эффективности своих основных фондов. Другим полезным показателем может быть "Возврат на возможность" (Return on opportunity). Он не является формальной финансовой метрикой, но описывает влияние инвестиций на бизнес. Подробнее обсуждение возможных финансовых инструментов содержится в курсе "ИТ-стратегия".

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

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

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

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