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

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

Размеры и характер деятельности организации, а также масштабы преобразований и модернизации диктуют глубину и степень детализации проработки архитектуры и ее поддержания в актуальном состоянии [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.

Таблица 1. Категории несоответствий в gap-анализе

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

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

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

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

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

• "жесткие" несоответствия, которые связаны, например, с необходимостью замены ряда технологий или внедрения новых;

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

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

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

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

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

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

• направление развития ИТ – определяет среднесрочные и перспективные роли ИТ в компании с учетом требований бизнеса и выделенных приоритетов;

• принципы реализации – определяют "правила" рассмотрения, внедрения и последующего управления технологиями;

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

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

• Общие ИТ-службы. Сюда относятся кросс-функциональные и служебные приложения, такие как электронная почта.

• Вычислительная инфраструктура. Корпоративные стандарты на технологии и средства инфраструктуры должны базироваться на применении общепризнанных ИТ-стандартов.

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

Таблица 2. Шаблон модели развития элементов технологической архитектуры

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

• стратегии развития, перспективности расширения бизнеса, изменения отношений с клиентами и поставщиками;

• общемировых тенденций развития информационных технологий;

• выбранного направления развития ИТ-технологий в организации и стратегии реализации (срочные, среднесрочные и перспективные этапы).

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

Таблица 3. Пример рассмотрения модели развития в области системного программного обеспечения

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

• большое количество эксплуатируемых приложений, использующих форматы DBF, FoxPro и MS SQL Server версии 7;

• корпоративная электронная почта отсутствует, например, пользователи используют почтовые ящики на общедоступных публичных серверах;

• большое количество версий эксплуатируемых операционных систем, в том числе устаревших и т.п.

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

• переход в ближайшее время на Windows XP;

• внедрение корпоративной электронной почты MS Exchange/Outlook;

• в качестве целевой платформы СУБД и серверов приложений выбран Oracle – то есть новые приложения будут использовать СУБД Oracle, а в перспективе будут реализованы с поддержкой J2EE и выполняться на Oracle AS. В то же время существующие приложения, использующие MS SQL Server, будут сохранены;

• в течение ограниченного времени будет поддерживаться и формат DBF для обеспечения интеграции с унаследованными приложениями;

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

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