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

Раздел: Информационные технологии
Автор(ы): Гален Груман (Galen Gruman), журнал "IT-Менеджер" (№1, 2007)
размещено: 23.04.2007
обращений: 9263

В экслюзивном обзоре Массачусетского технологического института (МТИ) описывается эволюция IT-архитектуры предприятия и даются подробные пояснения, почему нельзя обойти ни одну из предложенных стадий.
Шел 1999 год, и упоминание о любых возможных неполадках, связанных с «проблемой 2000 года», вызывало повышенный интерес со стороны IT-службы гигантского провайдера финансовых услуг — корпорации «State Street». Но, несмотря на повышенную концентрацию усилий на решении этой проблемы (нужно, чтобы «00» не было интерпертированы системами как 1900 год), Дэвид Соул, менеджер по системному программному обеспечению и ведущий специалист по устранению «проблемы 2000» корпорации, осознал кое-что еще. Все проекты по корректировкам были связаны между собой — значит, чтобы обеспечить изменения в приложении А, не вызывая проблем в приложении В, команда проекта должна понимать взаимосвязи и механизмы взаимодействия различных корпоративных приложений.

Например, корпоративные приложения используют справочные данные для обработки защищенных транзакций (валюта, обменный курс, по которому проводилась сделка, и т.п.). Ввиду того, что этими данными пользуются все приложения, команде Соула логично работать с ними независимо от специальных финансовых приложений, использующих эти данные. В то же время, большинство приложений работают со своими собственными справочными данными, а не полагаются на отдельный общий сервис. Осознавая ценность общих сервисов, корпорация «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.



comments powered by HyperComments
ЧИТАЙТЕ ТАКЖЕ:КНИГИ ПО ТЕМЕ:
Софт за 30 дней. Как Scrum делает невозможное возможнымСофт за 30 дней. Как Scrum делает невозможное возможным
В постели с Google. Передовые способы оптимизации поискаВ постели с Google. Передовые способы оптимизации поиска
Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидингаИдеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга
Викиномика. Как массовое сотрудничество изменяет всеВикиномика. Как массовое сотрудничество изменяет все
Верховный алгоритм. Как машинное обучение изменит наш мирВерховный алгоритм. Как машинное обучение изменит наш мир

Отзывы

Абсурд, abcurd@mail.ru
очень актуально для тех, кто на волне ИТ-безгамотности первых лиц крупных компаний доверяет своим ИТ-директорам, не обладающих знаниями о логике управления предприятием!
2007-05-03 15:38:03
Ответить



Примечание: Точка зрения авторов статей может не совпадать с точкой зрения редакции Management.com.ua.
Для авторов: Редакционная политика портала.
система корекції помилок Внимание! На сайте работает система коррекции ошибок. Найдя ошибку в слове (фразе), выделите его и нажмите Ctrl+Enter.



bigmir)net TOP 100

МЕТОДОЛОГИЯ: Стратегия, Маркетинг, Изменения, Финансы, Персонал, Качество, ИТ
АКТУАЛЬНО: Новости, События, Тенденції, Интервью, Бизнес-образование, Комментарии, Рецензії, Консалтинг
СЕРВИСЫ: Бизнес-книги, Работа, Семинары, Форумы, Глоссарий, Цитаты, Рейтинги, Ресурсы, Статьи партнеров
ПРОЕКТЫ: Блог, Видео, Визия, Визионеры, Бизнес-проза, Бизнес-юмор

Страница Management.com.ua в Facebook    Management Digest в LinkedIn    Отслеживать нас в Twitter    Подписаться на RSS    Почтовая рассылка


Copyright © 2001-2017, Management.com.ua
Портал создан и поддерживается STRATEGIC

Подписка на Менеджмент.Дайджест

Получайте самые новые материалы на свой e-mail (1 раз в неделю)



Спасибо, я уже подписан(-а)