Экосистема корпоративной архитектуры

Что такое корпоративная архитектура?

Важно понимать смысл обоих слов этого понятия. Архитектура — это средство представить и понять сложную систему с помощью моделей и их анализа. Архитектура позволяет описать систему и контролировать ее. Второе слово —«корпоративная» — вызывает много дискуссий. Подчас под «корпоративной архитектурой» понимается ИТ-архитектура компании или даже архитектура отдельного решения. Я считаю, что понятие корпоративной архитектуры должно иметь максимально широкий охват, рассматривать бизнес в целом, все его основные компоненты: людей, процессы и технологии. Корпоративная архитектура должна, представляя всю эту систему целиком, помогать правильно расставлять приоритеты проектов для бизнеса, опираясь на анализ двух ключевых факторов. Прежде всего, это их ценность для бизнеса. Но этот фактор не может быть единственным. Мы можем предложить фантастический проект, способный принести компании миллионы долларов, но насколько реально его выполнить? Поэтому второй фактор — возможность реализовать проект.

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

Каким образом эволюция ИТ влияет на развитие корпоративных архитектур?

Промышленная революция XIX века сделала технологии неотъемлемой частью бизнеса, однако с появлением компьютеров отношения между бизнесом и технологиями начали усложняться. В 60–70-е годы, когда началось использование мэйнфреймов, между бизнесом и технологиями стал возникать разрыв — появилась сфера, куда доступ бизнесу был закрыт, особая каста «людей в белых халатах». Но одновременно происходила все более активная автоматизация различных бизнес-процессов, появлялись решения типа SAP. И в конце концов возникла необходимость в инструменте, который помог бы разобраться во всей этой сложной среде, то есть нужна была архитектура.

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

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

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

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

Какие подходы к формированию корпоративной архитектуры соответствуют новой эпохе?

Наибольшие шансы трансформироваться в архитектуру нового типа имеет TOGAF (The Open Group Architectural Framework), потому что эта методология не только дает таксономию или архитектурный фреймворк, она включает в себя процесс достижения определенного бизнес-результата с помощью технологий с такими необходимыми атрибутами, как управление требованиями, мониторинг и т. д. Неправильно считать, что проект завершен, когда реализовано некое решение: мы разработали для вас CRM — наслаждайтесь! Такой подход неверен, корпоративная архитектура должна помогать выстраивать процесс, обеспечивающий достижение реального бизнес-результата от созданного решения.

В 2009 году мы разработали архитектурный фреймворк Value Realization Framework (VRF), в котором попытались расширить традиционную организацию ИТ, построенную по принципу plan — build — run («планирование — разработка — выполнение») и не имеющую связи с тем, чем занимается остальная компания. Мы добавили к этой цепочке четвертый этап — «реализация ценности для бизнеса» (value realization) — и возложили ответственность за этот этап на корпоративного архитектора. Раньше в его компетенцию входил только этап планирования — фактически судьба решения в реальной бизнес-практике его не интересовала. Если в сферу его ответственности входит реализация ценности для бизнеса на основе корпоративной архитектуры, он должен будет продумывать, как реализуются процессы развертывания, адаптации созданного решения, как будет выполняться управление изменениями.

Сейчас мы работаем вместе с Open Group — командой, которая развивает компоненты, относящиеся к бизнес-архитектуре TOGAF, с целью ее расширения элементами VRF. Мы пытаемся объединить все положительные наработки методологии TOGAF с новыми возможностями, которые позволят включить в архитектуру бизнес-стратегию. Надеемся, что это удастся реализовать к выходу новой версии TOGAF 10, который ориентировочно состоится в 2014 году.

Какие подходы вы используете в центре компетенции Microsoft?

В моем подчинении более 500 корпоративных архитекторов. Мы занимаемся консалтингом в области корпоративной архитектуры и приведением ее в соответствие со стратегией предприятия. Наша основная задача — стимулировать корпоративных архитекторов к созданию архитектуры, ориентированной на реализацию ценности для бизнеса. Мы начали заниматься этим в 2002 году. Я долгое время принимал участие в создании фреймворка Microsoft Business Solution Architecture (MBSA), а «перезагрузка» нашей собственной деятельности произошла в 2009 году, когда центральным элементом стал фреймворк VRF. Мы решили объединить разработанную в Крэнфилдском университете (Великобритания) модель Benefit Dependency Network (BDN), которая связывает ИТ-проекты с изменениями, проводимыми бизнесом, и модели бизнес-функций организации (business capability model). Модели бизнес-функций — достаточно зрелая область, последнее время мы тесно сотрудничаем с организацией American Productivity&Quality Center (APQC), которая стандартизировала наборы процессов, охватывающие различные подразделения. А если говорить об ИТ-организации, то ее многочисленные функции (capability) обеспечивают возможность предоставлять сервисы бизнесу, и в этой области есть прекрасно проработанный стандарт — ITIL. Microsoft предлагает свою версию ITIL — Microsoft Operations Framework (MOF).

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

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

Существуют ли какие-либо стандарты моделирования возможностей людей?

Модели возможностей людей (people capability model) — очень интересная и пока мало проработанная область корпоративной архитектуры. Сейчас складываются новые подходы к организации работы сотрудников — например, принцип «work at loud», когда вы находитесь в постоянном взаимодействии со своими коллегами и, вместо того чтобы сообщать о каких-то свершившихся фактах, ставите их в известность о своих планах и намерениях. Для этого используются корпоративные социальные инструменты. Представьте себе: сейчас 9 часов, вы заканчиваете свой утренний кофе и собираетесь заняться отчетом по глобальной дистрибуции. Вы сообщаете об этом в сети, это видит ваш коллега и предлагает документ или ссылку, которые помогут вам лучше разобраться в теме. Благодаря тому, что о вашей работе знают в вашей группе, отделе или даже во всей компании, вы сможете взаимодействовать с другими сотрудниками в реальном времени и получать важную информацию. Но для того чтобы это работало, в организации должна сложиться определенная культура открытости, люди должны иметь не только возможность, но и желание и волю делиться опытом, знаниями, работать совместно.

Как оценить корпоративную архитектуру, какие для нее возможны показатели эффективности?

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

В Microsoft накопили большой опыт такого планирования. Например, у нас есть так называемые Product Line Architecture — архитектуры для оптимального развертывания и использования продуктов корпорации, благодаря которым наши клиенты, приобретая определенные решения и сервисы компании, не должны каждый раз заново искать способы их применения. Мы знаем, как это сделать лучшим образом в различных ситуациях.

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

Какими полномочиями в компании должен обладать корпоративный архитектор?

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

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

Какую роль правильно выстроенная корпоративная архитектура может сыграть в снижении рисков бизнеса?

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

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

Наталья Дубова (osmag@osp.ru) — научный редактор, «Открытые системы.СУБД» (Москва).