Четыре стадии создания корпоративной архитектуры

Например, корпоративные приложения используют справочные данные для обработки защищенных транзакций (валюта, обменный курс, по которому проводилась сделка, и т.п.). Ввиду того, что этими данными пользуются все приложения, команде Соула логично работать с ними независимо от специальных финансовых приложений, использующих эти данные. В то же время, большинство приложений работают со своими собственными справочными данными, а не полагаются на отдельный общий сервис. Осознавая ценность общих сервисов, корпорация «State Street» сформировала Центр управления архитектурой (его возглавил Соул), который и был призван разработать архитектуру этих сервисов.

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

Все это, конечно, хорошо. Но даже если SOA — это действительно то, что нужно для вашего предприятия, вы просто можете быть не готовы к его разворачиванию. Это одно из заключений, которые можно сделать на основании двух исследований, недавно проведенных Центром исследования информационных систем Слоуна (ЦИИС) Массачусетского технологического института. Исследования «IT-архитектура как стратегия» и «Стратегические решения, принятые под влиянием IT» базируются на серии исследовательских проектов, реализованных в 1996-2006 годах и охватывающих 456 предприятий. Исследование ЦИИС выделяет 4 стадии в создании архитектуры систем: хаотичное хранилище бизнес-данных, стандартизация IT, стандартизация бизнес-процессов, модульная бизнес-организация. Эти стадии должны пройти бизнес-единицы вместе с IT-департаментами, прежде чем все преимущества сервис-ориентированной архитектуры будут реализованы в полной мере, и никто не может обойти ни одну из стадий.

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

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

По словам Росса, каждая стадия длится около пяти лет, хотя длительность можно сократить, поскольку многие компании проходят через определенную стадию и проводят «работу над ошибками». «Семь лет назад у исследовательских компаний не было практики по работе с архитектурой систем», — отмечает Соул из «State Street».

Хорошей новостью Росс считает тот факт, что конкуренты находятся приблизительно на таком же (или почти таком) уровне готовности архитектуры, как и ваша компания, и они точно так же не могут миновать ни одну из стадий.

SOA-мания

Сегодня IT-директора уже не могут обойтись без SOA. Исследовательские компании и коммерческие СМИ буквально «раструбили» о своих возможностях сделать компании динамичными и эффективными. Вендоры используют лейблы и слоганы, зачастую неправдоподобные, но способствующие продаже их продуктов. Куда бы ни обращались CIO, везде они услышат одно и то же: «вы должны развернуть SOA — причем как можно быстрее, иначе лишитесь преимуществ по сравнению с конкурентами».

На самом деле SOA-подход дает вам преимущества, даже если вы еще находитесь на той стадии, когда (по данным ЦИИС) предприятие не может в полной мере получить все плюсы. «Если вы развернете SOA-технологию до того, как ваша организация будет к этому готова, вы можете получить в результате более эффективную интеграцию IT-систем», — говорит Рон Шмельцер, главный аналитик консалтинговой компании «ZapThink», специализирующейся в том числе на SOA. Внедрение концепции SOA, даже в ограниченной форме — к примеру, создание веб-сервисов — «способствует созданию общего словаря, так что бизнес и IT начинают двигаться в одном направлении», — отмечает Джудит Хурвиц, генеральный директор консалтинговой фирмы «Hurwitz & Associates».

«Но пока вы пытаетесь насладиться положительными сторонами преждевременного внедрения SOA», — говорит Джим МакГрейн, бывший IT-директор (теперь вице-президент) известного бумажного производителя «MeadWestvaco», — «вы можете «пожинать» и некоторые негативные последствия. Использование веб-сервисов на плохо налаженных процессах делает их просто более заметными».

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

Стадия 1: от хаотичного хранилища данных к модульной структуре

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

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

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

Переход из стадии 1 в стадию 2 в основном обеспечивается работой IT-департамента, с обещанным возвратом инвестиций (ROI) и снижением уровня затрат. Но переход к стадиям 3 и 4 требует коренных изменений. Насколько — зависит от того, насколько IT-службы могут выполнять срочные и четко поставленные бизнес-единицами требования для развития бизнес-процессов, что можно осуществить благодаря гибким IT-сервисам с модульной структурой.

Стадия 2: уровень платформы

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

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

Следующий вопрос — определить, как внести изменения в существующие системы, чтобы они соответствовали новым стандартам. Не только IT должны перейти на новую технологию, на нее должны перейти и пользователи.

«Более тонкий момент в переходе к стадии 3 — это человеческий фактор», — говорит Джон Петри, вице-президент и директор по IT финансовой компании «TD Banknorth». На первой стадии бизнес-подразделения и их сотрудники концентрировались (и понятно почему) на решении своих отдельных специфических проблем. Для тех, кто этим занимается, стандартизация технологий означает потерю контроля и даже, возможно, нехватку оптимальных решений.

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

Стадия 3: Организация совместной работы

Как только организация приходит к единому стандарту платформ, следующая по логике площадка, где нужно повышать эффективность — бизнес и IT-процессы. Например, как рассказал Карл Вочс, IT-директор химического производственного предприятия «Celanese», они сэкономили около 40% средств, выделенных на IT, благодаря четырехлетним усилиям по стандартизации и консолидации, когда несколько центров обработки данных были объединены в один, а 13 ERP-систем также заменили на одну. Консолидация была начата еще на второй стадии, на уровне платформы, и завершилась на третьей стадии, когда компания смогла начать стандартизацию бизнес-процессов, необходимую для перехода компании на единую ERP-систему.

Переход от второй стадии к третьей может принести мало заметные (на первый взгляд) преимущества. В «TD Banknorth» бизнес-единицам для поддержания конкурентоспособности требуются все более сложные продукты, а это требует от IT-служб постоянного усовершенствования своих возможностей и повышения уровня сложности. В то же время, необходимость снижать затраты вынуждает CIO поставлять более сложный инструментарий, имея в наличии те же ресурсы. В результате они вынуждены прибегать к оптимизации, а тем самым переводят компанию на третью стадию построения архитектуры.

На третьей стадии архитектура начинает значить больше, чем IT-инфраструктура. Архитектура систем, управление IT, оптимизация процессов по методологии Six Sigma (Шесть сигм), совмещение IT с бизнесом стали критически важными аспектами с точки зрения архитектуры предприятия, при этом основной упор делается на повышении уровня IT — с управления эффективностью технологий до оказания влияния на успех бизнеса. Как говорит Д.Петри, «эффективность остается важным моментом, но основная цель изменилась — это уже не экономия средств, а снижение затрат для освобождения ресурсов, которые могут быть использованы для развития бизнеса».

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

Стадия 4: Модульная бизнес-организация

Совсем мало предприятий находятся сегодня на четвертой стадии — это всего лишь 6% из исследованных ЦИИС 450 предприятий.

На последнем этапе третьей стадии IT-руководители уже могут четко представлять, как должно выглядеть предприятие на четвертой стадии. IT-директор «Celanese» К.Вочс говорит, что некоторые подразделения его компании уже перешли на четвертую стадию и фокусируются на модульных процессах, которыми легко можно управлять в рамках архитектуры всего предприятия. «Компании могут быть динамичными, только если они могут подключать и отключать необходимые специфичные функции, — утверждает Вочс, — а это требует понимания, что это за функции, где они используются и на что влияют, что в свою очередь требует разработки гибкой и согласованной архитектуры».

Компания «State Street» полагает, что они находятся в начале четвертой стадии — по словам Соула. «Мы знаем, что нашему IT-персоналу нужно лучше разбираться в бизнес-процессах и коммуникациях, — говорит он. — Границы между IT и бизнесом стираются, и уже ясно, что кому-то нужно управлять и тем, и другим». Для некоторых компаний это означает, что IT могут стать частью общих сервисов и процессов.

Движение без остановок

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

Фактически — ввиду слияния компаний, разного уровня бизнес-потребностей или внешних факторов (таких, как регламентирующие документы), компании часто обнаруживают, что они в одно и то же время находятся на разных стадиях. Например, в компании «Celanese» система управления кадрами находится на второй стадии, ввиду требований к персоналу, а в то же время другие подразделения компании вступают в четвертую стадию.

«Предприятия должны также понимать, что архитектура никогда не будет завершена, — говорит Шмельцер, аналитик из «ZapThink». — Идея в том, чтобы постояно изменять сервисы, как, например, объединять два сервиса более низкого уровня в один, или наоборот. Обычно у CIO нет таких навыков, но у них должен быть архитектор системы или команда по разработке архитектуры, отчитывающаяся непосредственно перед ними».

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

Оригинал статьи: "The Four Stages of Enterprise Architecture" by Galen Gruman, December 01, 2006 — CIO.com.