 |
Когда мы говорим о том, что ИТ сегодня как никогда близки к бизнесу (а читать эту мантру, кажется, придётся еще долго), мы зачастую имеем в виду способы непосредственного влияния информационных технологий на бизнес-показатели. Однако такая постановка вопроса фактически делает CIO не столько ИТ-руководителем, сколько корпоративным архитектором, ибо ему приходится выстраивать взаимосвязи на всей вертикали — от фронт-энда и клиентских интерфейсов до инфраструктуры, которой он и должен управлять.
Притом что архитектура предприятия или Enterprise Architecture — понятие куда более широкое, нежели ИТ-инфраструктура. Но зачастую архитектурные работы ложатся именно на ИТ-руководителя, так как многие популярные методологии EA предполагают вертикальное строительство снизу вверх — от инфраструктурного бэк-энда к фронт-энду на уровне интерфейсов или приложений. При этом в исконном своем значении архитектура предприятия — это понятие, описывающее текущее и целевое состояние корпоративной системы, состоящей из приложений, бизнес-процессов, ИТ-инфраструктуры и работающей в тесном согласовании с бизнес-стратегией компании.
По сути же, EA — это не что иное, как способ выстраивания системы управления и взаимодействия на предприятии. Это создание текущей и целевой модели предприятия и преобразование компании из одного состояния (текущего) в другое (целевое). Такой процесс называется ведением архитектуры и направлен на интерпретацию и поддержку реализации целей организации посредством планирования и внедрения описаний и представлений в области бизнес-архитектуры, архитектуры приложений, архитектуры данных и технической архитектуры.
В идеальной ситуации отсюда должно возникать понимание того факта, что ИТ-стратегия и архитектура предприятия пересекаются как диаграмма Венна: ИТ-инфраструктура является частью EA, в то время как и архитектура предприятия не охватывает ИТ-стратегию целиком. С одной стороны, понятие архитектуры предприятия покрывает важные для ИТ-стратегии компоненты, оставляя за рамками элементы привычных для ИТ-департамента процедур планирования, методов управления, организации работы и поддержки. С другой же — в большинстве компаний нет чёткого процесса ведения EA, следовательно, архитекторы ключевых направлений (бизнес-архитекторы, технические и корпоративные архитекторы) попросту отсутствуют.
Различие проектов по построению архитектуры предприятия и ИТ-стратегии хорошо видно на примере того, что при разработке ИТ-стратегии большое внимание уделяется формированию принципов управления техническими ресурсами. А при проектировании EA проработка ИТ-ресурсов ведется только на уровне подготовки документации для групп архитекторов. В частном случае — технического архитектора. Однако, как уже было сказано, зачастую необходимых архитекторов на предприятии просто не оказывается, а это означает, что выстраиванием и ведением архитектуры предприятия занимается... да, именно CIO.
Определённая справедливость в этом есть, ведь нередко архитектура предприятия начинается именно с ИТ-решений, и многие методологии EA созданы самими ИТ-вендорами. Последние, конечно, воспринимают архитектуру предприятия как способ продать очередной продукт, но это не служит индульгенцией на игнорирование необходимости выстраивать EA. Впрочем, для ИТ-руководителя работа над архитектурой предприятия зачастую напоминает ленту Мёбиуса. В том смысле, что с одной точки поверхности на другую можно попасть, не пересекая края. Аналогия становится понятна в тот момент, когда, приступая к планированию архитектуры предприятия, CIO обнаруживает тесную взаимосвязь бизнес-приложений и прочих бизнес-юнитов с ИТ-инфраструктурой во влиянии на конечные перспективы EA-проекта.
Логично, что понимание конкретных нужд, связанных с ИТ-инфраструктурой в рамках EA-проекта, зависит от осознания того, какие приложения будут запущены на этой инфраструктуре. Для того чтобы понять потребности этих приложений, нужно узнать, какую информацию и типы данных они будут обрабатывать. Чтобы выяснить типы данных, требуется понять, каким образом бизнес будет использовать эту информацию. Это, в свою очередь, предполагает, что мы знаем задачи бизнеса — а следовательно, и стратегию компании. Последнее автоматически предполагает нашу осведомлённость о стратегии бизнеса и экосистеме, в которой существует компания.
Получается, что вертикаль с уровня информационных систем до уровня рынка, на котором оперирует компания, завязана сама на себя, как пресловутая лента немецкого математика. А если ИТ-директор не понимает хотя бы одного из вышеперечисленных уровней, то весь проект завязнет на этапе ИТ-архитектуры, которая в итоге окажется неподходящей, так как не будет поддерживать архитектуру предприятия на каком-либо из уровней (например, для функционирования всех приложений и автоматизации процессов будет недостаточно инфраструктурной мощности).
Поэтому подход к реализации проектов по архитектуре предприятия надо коренным образом изменять — и, согласно прогнозам многих экспертов, он будет меняться. К примеру, автор множества книг и признанный эксперт Enterprise Architecture Том Грейвс (Tom Graves) считает, что бизнесу необходимо воспринимать архитектуру предприятия как архитектуру именно предприятия, а не как корпоративных ИТ.
Конечно, построить такую систему, где каждый уровень, от ИТ-инфраструктуры и приложений до клиентских интерфейсов, завязан друг на друга, — непростая задача. Но такая структура действительно будет эффективно работать, в отличие от той, что основана исключительно на ресурсах ИТ-инфраструктуры. И, что немаловажно, правильная архитектура предприятия поможет сэкономить немало средств за счёт снижения операционных затрат на ИТ и хорошо отлаженного менеджмента, усиленного автоматизацией многих процессов. Так что усилия, определённо, стоят результата, который можно получить.
Главное, что CIO в целом по плечу построение правильной архитектуры предприятия. Но такой масштабный проект лучше передать команде специалистов, работающих на самых разных уровнях. Если применить зодческую аналогию, то у города, конечно, есть главный архитектор, но он занимается скорее согласованием проектов. А за каждым зданием стоит другой мастер, в сознании которого возник проект и который его воплотил.
|
|
