Корпоративная архитектура уже не ограничивается составлением схемы и обеспечением стандартизации оборудования и ПО. Сегодня речь здесь идет еще и о службах, событиях, а также о старой доброй окупаемости.
Корпоративная архитектура уже не ограничивается составлением схемы и обеспечением стандартизации оборудования и ПО. Сегодня речь здесь идет еще и о службах, событиях, а также о старой доброй окупаемости.
|
| Директор информационной службы компании Dow Jones Билл Годфрей считает, что «интеграция всего подряд в единую систему далеко не всегда имеет смысл» |
Директор информационной службы компании Dow Jones Билл Годфрей вспоминает свой первый выход в свет в качестве корпоративного архитектора в 1999 году — уверенный, агрессивный; казалось, находящиеся поблизости даже могли слышать позвякивание шпор. «Я начал с должности главного архитектора — шерифа с огромной звездой, внушительным креслом и бесчисленными слайдами PowerPoint, которые только можно достать за деньги, — вспоминал Годфрей. — Со временем все это доказало свою полную несостоятельность».
Корпоративный архитектор в «первой версии», как вспоминает сегодня Годфрей, не отвечал цели создания во всех основных подразделениях Dow Jones унифицированной архитектуры ИТ (стандартизированного оборудования и программных систем), тесно увязанной с бизнесом и его стратегией. По мнению Годфрея, это не работало, потому что чрезмерно большая власть была предоставлена всего одному человеку, от которого требовали слишком многого. Когда архитектор-шериф пытался наладить взаимодействие с представителями основных подразделений, его просьбы оставались без ответа. Его воспринимали как полицейского, который запрещает людям использовать полезные, на их взгляд, технологии.
«Нам не удалось в достаточной степени проникнуть вглубь информационных потоков бизнеса, — пояснил Годфрей. — Проект скорее можно было рассматривать как способ уединения, перемещение в башню из слоновой кости».
Пришлось приспосабливаться. Годфрей отказался от должности главного архитектора и в 2001 году сформировал объединенную структуру архитекторов основных подразделений, которые делились друг с другом накопленным опытом и координировали свои усилия в масштабах компании в целом. Цель оставалась прежней, однако Годфрей поменял свою большую звезду и слайды PowerPoint на сотрудничество и привозные обеды.
Впрочем, и это тоже не сработало.
Архитекторы по большей части действовали в интересах руководителей основных подразделений, которым для удовлетворения потребностей своего бизнеса требовалось то одно, то другое приложение. «Архитекторам просто не хватало времени для совместной работы над корпоративной архитектурой», — вспоминал Годфрей.
В июне 2004 года Годфрей вновь набрался решимости и приступил к реализации проекта Enterprise Architecture Version 3.0, который вобрал в себя черты обоих подходов. Он создал так называемый совет архитектурных зон, возглавляемый вице-президентом по ИТ, который подчинялся непосредственно Годфрею. Кроме того, в совет входили три архитектора и семь старших технологов, осуществлявших управление разрабатываемой архитектурой. (Более подробно вопросы управления корпоративной архитектурой рассмотрены во врезке «Корпоративная архитектура нуждается в управлении».)
Годфрей наделил группу самыми широкими полномочиями. Любой руководитель в Dow Jones, желающий потратить на проект более 250 тыс. долл., должен был получить одобрение архитектурной группы. Чтобы раздобыть деньги, руководителям проектов требовалось представить свои планы, а архитекторы уже решали, соответствуют ли цели проекта и выбранная технология общей стратегии бизнеса и технологической стратегии Dow Jones. Некоторые представители основного бизнеса — и даже часть сотрудников ИТ-службы — высказывали недовольство тем, что Годфрей распространил полицейские запреты буквально на все, но зато теперь, по крайней мере, правила игры и цели (сокращение расходов, усиление стандартизации, ускорение разработки) видны достаточно ясно. По словам Годфрея, говорить о том, окажется ли удачной третья попытка, еще слишком рано, но тем не менее надежды он не теряет: «Я уверен, что в конечном итоге мы сумеем найти нужный баланс, и в 2005 году планирование капиталовложений, процедуры реализации проектов и культура работы предприятия сформируются на основе корпоративной архитектуры».
Сегодня практически каждый директор информационной службы считает своим долгом заниматься вопросами построения корпоративной архитектуры, и начало реализации в Dow Jones третьей версии проекта ее формирования вполне отвечает духу времени. В большинстве компаний создается небольшая централизованная группа (по оценкам аналитиков Forrester, в 84% организаций в ее работе принимает участие до десяти человек, причем от размеров предприятия это не зависит). Группа раздает пряники (деньги), но вместе с тем и не выпускает из своих рук увесистый кнут (осуществляет контроль над проектом). Цели ее заключаются в том, чтобы обеспечить согласованность, стандартизацию, добиться повторного использования существующих ИТ-ресурсов, а также применять при управлении проектами и разработке программного обеспечения общие методы в масштабах всей компании. В конечном итоге корпоративная архитектура должна способствовать удешевлению информационных технологий, усилить их стратегическую направленность и заставить их более чутко реагировать на изменение потребностей компании в целом.
Претворение в жизнь безумных идей или же, напротив, трезвая оценка открывшихся не так давно возможностей все чаще приводит к тому, что руководители информационных служб — и подчиненные им организации — постепенно начинают обращать внимание на новую теорию.
Из мрака на свет
Корпоративная архитектура долгое время оставалась концепцией, о которой вслух говорить было не принято. Многие руководители информационных служб избегали использования соответствующей терминологии, опасаясь проявления недовольства и враждебности со стороны начальников основных подразделений или же просто из чувства самосохранения. Однако компании (в частности, Dow Jones, T-Mobile и Verizon), руководство которых отважилось на подобный эксперимент, уже через очень короткий срок пожинали плоды экономии, гибкости и обеспечения согласованности ИТ с бизнесом, о которых сторонники данной концепции говорили на протяжении почти 20 лет.
За прошедшее время концепция не претерпела особых изменений: она по-прежнему напоминает градостроительство в области информационных технологий, составление общего плана интеграции данных, бизнес-процессов и ИТ-ресурсов в рамках всей компании, определение порядка их использования и путей построения необходимых для этого механизмов.
Подобная инициатива всегда считалась масштабной, сложной и дорогостоящей, и ее окупаемость с точки зрения бизнеса представлялась весьма туманной. Было очевидно, что стандартизация, планирование и управление ИТ-ресурсами не сделают бизнес более гибким, разносторонним или прибыльным. В результате все усилия по созданию архитектуры ИТ либо терпели неудачу либо были ориентированы исключительно на информационные технологии.
Но сегодня ситуация начала меняться. Развитие интеграционных технологий — главным образом интеллектуального и гибкого промежуточного ПО и Web-служб — открывает новые способы проектирования гибких и хорошо адаптируемых корпоративных архитектур, которые обладают ценными для бизнеса качествами. С этими новыми архитектурами информационные технологии позволяют реализовать необходимые функции быстрее, дешевле и на понятном представителям бизнеса языке.
Открывшиеся возможности способны вдохнуть новую жизнь в ряд старых концепций, стимулировать создание новой корпоративной архитектуры и возродить проекты, которые в свое время не увенчались успехом.
Первая концепция связана со службами и известна как сервис-ориентированная архитектура (SOA). SOA позволяет реализовать те программы, которые в условиях старой корпоративной архитектуры не выходили за рамки пустых обещаний.
Идея, положенная в основу служб, довольно проста. Технологию следует рассматривать в качестве составной части бизнеса, а не некоего таинственного приложения типа EPR или CRM. Директор ИТ-службы компании Verizon Шейган Херадпир заявил, что в репозитариях его сети intranet находится свыше 200 служб, выполняющих самые различные задачи, начиная от проверки кредитоспособности и заканчивая ведением учетных записей клиентов. Представители бизнеса могут обращаться к службе на понятном им языке, а информационные технологии быстро устанавливают связь с другими службами для формирования потока работ, а при необходимости и для построения нового приложения. Эти приложения создаются очень быстро, потому что сложные, тщательно спроектированные интерфейсы позволяют разработчикам подключаться к службам без непосредственного обращения к их программному коду. Им не известно даже, как построены службы и на каком языке они написаны.
|
| Архитектура, построенная директором информационной службы компании Lydian Trust Джоном Стаддардом, создала предпосылки для того, чтобы «завершить проектирование новой системы уже через несколько дней или недель, не тратя на это несколько месяцев». |
Вторая концепция, продвигающая сегодня корпоративную архитектуру, основана на событиях. В качестве первопроходцев здесь выступали телекоммуникационные компании и поставщики финансовых услуг. Согласно данной концепции, информационные технологии призваны осуществлять контроль за бизнес-процессами с точки зрения происходящих событий — регистрируя, например, возникновение дефицита товаров на складе или подозрительно большие проводки по клиентской кредитной карте, — и автоматически предупреждать людей о необходимости принятия соответствующих мер. Службы и события совершили революцию в вопросах проектирования корпоративной архитектуры, предоставив директорам предприятий, а также руководителям информационных и финансовых служб ту гибкость и набор полезных функций, которые все эти годы они пытались (чаще всего безуспешно) отыскать.
Службы и события не описывают корпоративную архитектуру, но формируют ее новое ядро. Руководители информационных служб, занимающиеся построением корпоративной архитектуры без использования служб и событий, упускают возможность удовлетворить две разновидности наиболее устойчивых — и четко сформулированных — претензий, предъявляемых представителями бизнеса к ИТ-службе. Претензии эти связаны с недостаточной гибкостью и оперативностью.
«Сегодня мы можем завершить проектирование новой системы уже через несколько дней или недель, не тратя на это несколько месяцев», — отметил Джон Стаддард, директор ИТ-службы банка Lydian Trust, интегрировавший в свою корпоративную архитектуру как службы, так и события.
Построение фундамента и обход ловушек
Суть корпоративной архитектуры заключается в том, чтобы разработать план использования ИТ-ресурсов и бизнес-процессов, а также совокупность принципов управления, позволяющих выразить стратегию бизнеса через информационные технологии. Для построения корпоративной архитектуры существует множество различных структур (см. врезку «С чего начать»). Большинство из них включает в себя четыре основных компонента:
- информационная архитектура определяет места хранения важных блоков информации (например, учетных записей клиентов) и порядок доступа к ним
- архитектура инфраструктуры, совокупность аппаратных средств и сетевых технологий
- архитектура приложений, порядок взаимодействия прикладных программ друг с другом
- бизнес-архитектура, схема наиболее значимых бизнес-процессов компании.
Последний компонент наиболее важен, но он является и самым сложным. Даже если сотрудникам ИТ-службы удастся убедить руководителей основных подразделений уделить достаточное внимание обсуждению данных вопросов, добиться от них единодушия в ходе определения наиболее важных процессов практически невозможно.
А когда руководители основного бизнеса все-таки оценят по достоинству значимость корпоративной архитектуры, их ждет еще одна неприятная новость. Построение корпоративной архитектуры — процесс очень дорогостоящий. По мнению аналитиков Forrester, привлечение на полный рабочий день четырех-шести архитекторов обойдется организации в сумму от 650 тыс. до миллиона долларов, а приглашение внешних консультантов для инициирования реализации данного проекта потребует расходов в размере примерно 100 тыс. долл. (Возможные способы сокращения капиталовложений описаны во врезке «Корпоративная архитектура при минимуме затрат».)
И тем не менее будущее информационных технологий связано именно с корпоративными архитекторами. Люди, хорошо разбирающиеся в технологиях и свободно ориентирующиеся в вопросах бизнеса, способны взять на себя роль пробивных консультантов и терпеливых дипломатов, выстраивающих между информационными технологиями и бизнесом мосты, которых так не хватает сегодня ИТ-службам.
Ценность архитектуры — основное условие продажи ее бизнесу
«Когда в компаниях формируются группы по созданию корпоративной архитектуры, прежде всего их участникам следует быть готовыми к тому, что им придется преодолевать сопротивление», — отметил Хоссейн Мойин, вице-президент компании T-Mobile International, предоставляющей своим клиентам услуги беспроводной телефонной связи. Группа корпоративных архитекторов T-Mobile анализирует проекты, желая убедиться в том, что они грамотно проработаны, отвечают потребностям бизнеса и соответствуют архитектуре предприятия в целом. «Фактически речь идет о покупке проекта, — пояснил Мойин. — Представители бизнеса, а также некоторые сотрудники ИТ-службы, считают это бюрократией. Необходимо привести примеры, которые доказали бы ценность проекта».
К примеру, один из проектов T-Mobile предусматривал создание службы, которая позволила бы подписчикам настраивать мелодию своего звонка. Участники проекта предполагали, что большую часть программного обеспечения необходимо создавать с нуля. Однако группа архитекторов сумела найти код, который уже имелся в компании T-Mobile и мог быть использован в качестве основы для новой разработки. Повторное использование компонентов сократило цикл разработки по крайней мере вдвое. «Приведите ряд подобных примеров, и вам кого угодно удастся убедить в том, что контроль за архитектурой весьма полезен», — отметил Мойин.
«В страховой компании The Hartford процедура контроля помогла предотвратить построение нового интерактивного портала для агентов на базе архитектуры, не предусматривавшей масштабирования, — сообщил заместитель директора по распространению прикладной инфраструктуры Бен Морлэнд. — Нами изначально прогнозировалось расширение функциональности портала и увеличение числа обслуживаемых им пользователей. Проанализировав ситуацию на раннем этапе, мы внесли соответствующие коррективы и в дальнейшем смогли обеспечить требуемую масштабируемость».
Мнения руководителей информационных служб, с которыми нам удалось побеседовать относительно того, имеет ли смысл заниматься традиционным составлением схем для каждого сервера компании, разделились. На практике в ряде компаний, особенно больших, для которых характерна высокая степень децентрализации, это зачастую оказывается невозможным. Микки Лутц, директор информационной службы компании Cendant Travel Distribution Services — одного из таких крупных децентрализованных предприятий, не относит себя к числу сторонников подобного крупного, широкомасштабного отображения. Предлагаемый им компромисс заключается в том, чтобы составлять необходимые схемы только для удовлетворения потребностей конкретных проектов. «В одном из сегментов нашего бизнеса мы составляли такие схемы, но они инициировались проектами, — вспоминает он. — Люди занимались построением Web-служб, и им нужно было знать, где находятся все необходимые приложения и данные. Никто не видел, чтобы архитекторы уединялись в башне из слоновой кости. Необходимо было принимать участие в работе проектной команды и составлять схемы по мере возникновения у бизнеса потребности в этом».
Именно подобная чувствительность к потребностям бизнеса отличает новые, более эффективные реализации корпоративной архитектуры от прежних, ориентированных на информационные технологии. «В прошлые дни в команде, занимавшейся проектированием нашей корпоративной архитектуры, господствовала точка зрения, согласно которой компании нужна была одна биллинговая система, не важно какая, — вспоминал Годфрей. — Но далеко не всегда имеет смысл интегрировать в систему все подряд. Корпоративные архитекторы должны знать, когда лучше пойти на компромисс, а когда занять твердую и решительную позицию».
В компании Cendant, поставляющей информацию о расписании и ценах почти в 47 тыс. туристических агентств, Лутц и его архитекторы хорошо изучили, когда следует поискать компромиссное решение. Если, к примеру, при разработке нового продукта скорость выпуска его на рынок имеет критически важное значение, архитекторы Лутца готовы отказаться от процедуры контроля. Новым идеям иногда дается зеленый свет, так что команды, занимающиеся реализацией проектов, могут беспрепятственно вносить в них необходимые изменения с требуемой частотой. «Мы не воздвигаем строгих барьеров ради построения архитектуры как таковой», — пояснил Лутц.
Продвижение бизнеса в направлении, в котором он не желает двигаться, может погубить команду, выстраивающую корпоративную архитектуру. «Нужно стремиться к тому, чтобы превратиться во влиятельную силу, а не просто к власти», — отметил директор подразделения Financial Markets Group страховой компании Aegon USA по ИТ-стратегии Джефф Глисон.
Чтобы приобрести влияние, группе построения архитектуры необходимо учитывать стратегию ведения компанией своего бизнеса. Один из способов решения данной задачи заключается в создании на достаточно высоком уровне комитета по корпоративной архитектуре (с участием представителей основного бизнеса), который осуществлял бы контроль за деятельностью корпоративных архитекторов. Другим решением может стать выделение части рабочего времени архитекторов на консультации руководителей бизнеса в отношении ИТ-проектов, которые им хотелось бы реализовать. Независимо от использования формальных механизмов управления или проведения неформальных встреч с представителями основного бизнеса, корпоративным архитекторам отводится роль группы стратегических исследований, подчиненной директору ИТ-службы. Директор ИТ-службы изучает мнение архитекторов и использует полученную информацию для налаживания связей между ИТ и бизнесом.
А главным, пожалуй, звеном в процессе налаживания этих связей являются службы.
Почему отличным службам нужна отличная корпоративная архитектура
Шейгану Херадпиру для выполнения своей работы не требуются похвалы. Но когда речь заходит о Spider, директор ИТ-службы компании Verizon превращается в некое подобие рок-звезды. «Spider — единственное, за что я готов выслушивать аплодисменты на встречах с представителями бизнеса», — говорит он. Spider — это поисковый механизм, позволяющий найти клиентскую запись в любом месте внутри архитектуры Херадпира.
А тут есть где развернуться. В состав корпорации Verizon входят три разные компании (GTE, Bell Atlantic и Nynex), каждая из которых имеет свою собственную, настроенную с учетом ее потребностей компьютерную инфраструктуру. Однако благодаря инициативе, которую Херадпир начал претворять в жизнь, еще будучи директором ИТ-службы GTE, а затем в 2002 году перенес на все подразделения Verizon, был найден способ вылавливания информации о клиентах в территориальных водах любой из трех компаний. «Пытаясь консолидировать информацию разнородных систем, мы разработали у себя в GTE программу Oneness, — вспоминает Херадпир. — Однако инженеры выступили против. Они заявили, что не стоит заниматься консолидацией последствий большого взрыва. Вместо этого лучше сформировать общий набор Web-служб, которые подошли бы ко всем нашим системам».
Итак, вместо того чтобы искать пути консолидации всех систем, в которых содержалась информация о клиентах, инженеры Херадпира построили Web-службы, вобравшие в себя бизнес-правила и обеспечивающие доступ к нужным хранилищам данных. Процесс создания службы был сложным и дорогостоящим, но сделать это предстояло лишь однажды. К ней прилагался интерфейс (тоже сложный и трудоемкий в построении), упрощающий связь с клиентскими записями. Теперь, если возникала задача написать новое приложение, которому требовалось обращение к клиентской информации, достаточно было с помощью Web-служб быстро установить связь с интерфейсом клиентских записей, не занимаясь разработкой индивидуальных механизмов интеграции с многочисленными системами Verizon.
«На создание в такой большой компании, как наша, чего-то похожего на Spider с нуля ушли бы годы, — заметил Херадпир. — Но поскольку служба обработки клиентских записей была интегрирована в корпоративную архитектуру, наши программисты смогли построить соответствующую систему всего за два месяца. Это наш корпоративный механизм Google, и сотрудники, занимающиеся обслуживанием клиентов, очень любят его».
Однако чрезмерная популярность тоже имеет свои негативные последствия. «Разработчики стали активно обращаться к службе клиентских записей, как только получили доступ к ней, — вспоминает Херадпир. — Но они забыли объяснить людям, которые пользовались результатами их труда, что нагрузка на серверы увеличится в сто, а может быть, и в тысячу раз. В конце концов, службу пришлось отключить».
Этот урок заставил Херадпира понять, что расширяющемуся ассортименту служб требуется управление в рамках корпоративной архитектуры. Внутри сети intranet Verizon архитекторы построили репозитарий для создания, публикации и управления службами. Любой желающий мог узнать о наличии той или иной службы — например, службы проверки кредитоспособности или контроля адресов, но для того чтобы работать с ними, требовалось получить разрешение группы, отвечавшей за корпоративную архитектуру, и одобрение ИТ-службы. Специалисты оценивали потребность в новом проекте и нагрузку, которую он оказывал на инфраструктуру. Затем определялась значимость службы — ее уровень устанавливался совместно с представителями основного бизнеса, одновременно утверждался порядок оплаты за пользование ею. Принять правильное решение было непросто.
Корпоративные архитекторы занимались службами и при выполнении первоначальных процедур контроля за архитектурой. Херадпир заметил, что руководители проектов отказывались от создания служб в ходе разработки приложений и на этапе интеграции своих проектов. Это рассматривалось как дополнительная работа. Такое положение дел Херадпир счел достаточным основанием для включения служб в процедуру контроля. «Нужно подтолкнуть разработчиков к проектированию Web-служб, создать у них соответствующие стимулы, — отметил Херадпир. — Когда у них появится желание реализовать определенную функциональность, необходимо дать им соответствующее разрешение, но вместе с этим обязать заняться и Web-службами».
Поначалу разработчики ворчали, но в конце концов заметили, что в условиях быстрого расширения репозитария служб в выигрыше оказываются все. «Именно в этом направлении развивалась наша стратегия совершенствования корпоративной архитектуры, — пояснил Херадпир. — Сегодня разработчики могут зайти на Web-сайт и сразу начать писать код нужного им высокоуровневого приложения, не тратя времени на интеграцию и построение уровня инфраструктуры».
Что нужно знать о SOA
Службы требуют нового типа архитектурного мышления. Службы скорее похожи на уже готовые программные продукты, чем на проекты, предполагающие написание кода. Они должны быть обращены к самой широкой аудитории и допускать повторное использование для повышения производительности труда. По мнению корпоративного архитектора компании Lydian Trust Фрэнка Барбато, чтобы привлечь к использованию Web-служб разработчиков, которые в общем случае привыкли полагаться на собственные к силы, «нужно показать им, кто еще применяет в своей деятельности эти службы и каких достижений ему удалось добиться; вы продаете службы примерно так же, как продавали бы их внешнему клиенту».
Критически важное значение имеет планирование — не только силами сотрудников ИТ-службы, но и с привлечением представителей основного бизнеса. Первый серьезный вопрос, на который ссылаются знатоки SOA, связан с модульностью. Ранее разновидности служб определялись на слишком низком уровне инфраструктуры (в качестве простых примеров здесь можно привести функции «печати» или «сохранения») и не привлекали внимания представителей основных подразделений. Новое поколение служб определено на более высоком уровне; они описывают какой-то компонент бизнеса и представляют для него определенную ценность. К примеру, модуль «проверки кредитоспособности» имеет ценность не только для программистов, желающих использовать данный код в других приложениях, но и для сотрудников основных подразделений, которые хотели бы применять его сразу в нескольких продуктах — скажем, при оформлении ипотеки или кредита на покупку автомобиля — и в нескольких направлениях бизнеса.
Однако правильно определить уровень модульности оказывается сложнее, чем может показаться на первый взгляд. В компании T-Mobile Мойин попытался изначально сделать ставку на максимально высокий уровень модульности, а затем начал постепенно спускаться вниз. Первая служба становится своеобразным якорем и определяет порядок построения служб следующего уровня. К частности, в T-Mobile была создана высокоуровневая служба «отправки сообщения». Впоследствии команда, занимающаяся проектированием архитектуры, построила ряд служб уровнем ниже (в том числе «отправки SMS-сообщений»), которые обеспечивали пересылку сообщений в определенном формате на различные устройства (сотовые телефоны, пейджеры и т. д.), используемые клиентами в сети T-Mobile. Подобная методология движения от общего к частному помогла Мойину избежать построения служб, в которых не было надобности.
Связь между службами и событиями
События — это глаза и уши бизнеса, представленные в виде технологий, они помогают выявлять угрозы и открывающиеся возможности, предупреждая тех, кто должен принимать решения на основе полученной информации. Если службы делают корпоративную архитектуру более гибкой и отзывчивой, то события позволяют точнее формулировать предупреждения и обнаруживать проблемы еще до того, как они повлекут за собой негативные последствия (а также выявлять возможности до того, как они будут упущены). Использование событий для управления проектом архитектуры помогает информационным технологиям оказывать непосредственное воздействие на динамику прибылей и убытков бизнеса.
Наконец, подобно службам, события можно выразить в терминах, понятных представителям основного бизнеса. «Генеральный директор и директор финансовой службы — это люди, принимающие решения на основе происходящих событий, пояснил почетный профессор электротехники Стэнфордского университета и один из ведущих специалистов в области систем, управляемых событиями, Дэвид Лакхэм. — Когда вопрос становится достаточно актуальным, они начинают следить за серией связанных с ним событий, фиксируя то, что происходит, и продумывая свои возможные действия».
ИТ-службе необходимо приступать к построению архитектурных систем аналогичным образом. Специалисты по анализу событий начинают изучать те из них, которые оказывают влияние на всю компанию (дефицит поставок, неприемлемо долгое время ожидания ответа сотрудника call-центра и т. д.), и выстраивать ИТ-системы, позволяющие осуществлять контроль за подобными ситуациями и реагировать на их возникновение. К примеру, если система, контролирующая транзакции кредитных карт, обнаруживает прохождение платежа на сумму 10 тыс. долл. по карте, лимит которой составляет 2 тыс. долл., она выдает предупреждение диспетчеру и автоматически блокирует счет.
Несмотря на то что традиционно они рассматривались как разные технологии, службы и события связаны друг с другом. Поскольку сервис-ориентированные приложения и потоки работ не имеют жестких связей, а разработчики устанавливают соединения со службами, структура и состав которых им не всегда понятны и которые находятся вне зоны их контроля, при проектировании необходимо учитывать влияние событий.
Приведем пример. Корпоративные архитекторы Lydian Trust создали службу «получения кредита», которая применяется несколькими подразделениями компании для управления потоками работ различных кредитных приложений (управления ипотечным кредитом, кредитом на покупку автомобиля и пр.). «Получение кредита» — это Web-служба, проверяющая через Internet кредитные рейтинги, составленные ведущими кредитными бюро.
Как-то раз Web-серверы одного из кредитных бюро на несколько часов вышли из строя. Когда служба «получения кредита» Lydian Trust попыталась обратиться к ним, ответа не последовало. Поскольку жесткого соединения с сервером не устанавливалось, система не знала, что происходит. Служба «получения кредита» была рассчитана на однократное обращение к серверу. В ожидании ответа сотни кредитных приложений простаивали.
Сотрудники кредитных отделов вынуждены были работать всю ночь напролет для того, чтобы обеспечить выдачу ответа клиентам Lydian Trust в течение 24 часов. В результате клиенты так ничего и не почувствовали, а вот директор информационной службы Стаддард и корпоративный архитектор Барбато испытали далеко не самые приятные ощущения. «В сервисной среде существует очень много зависимостей, — пояснил Стаддард. — Система должна быть готова к возникновению определенных событий — или к отсутствию ожидаемого события — и не прерывать потока работ». Теперь в программный код службы «получения кредита» внесены изменения, предусматривающие обращение к серверам кредитного бюро в течение 22,5 час. И только если эти усилия не увенчаются успехом, происходит отказ в обслуживании. При возникновении каких-либо осложнений диспетчеру ИТ-службы автоматически высылается электронное письмо, а в случае отсутствия реакции с его стороны соответствующее предупреждение направляется на более высокий уровень. «Выработка алгоритмов подобного рода приходит лишь с горьким опытом, — пошутил Барбато. — В новых продуктах вы вряд ли увидите такое».
Магия корпоративной архитектуры
Готовых рекомендаций по созданию корпоративной архитектуры очень мало. Это уровень знаний, в которых обобщен уникальный опыт, накопленный каждой конкретной компанией, и учитывается сложившаяся в ней корпоративная культура. Однако разработка соответствующих внутренних процедур имеет критически важное значение для ликвидации разрыва, существующего сегодня между информационными технологиями и бизнесом. В нынешнюю эпоху автоматизации и аутсорсинга внутренние ИТ-службы просто обязаны проявлять гибкость, оперативность и быстроту реакции. «Если бы у меня была волшебная палочка, и можно было взмахнуть ею, все, что связано с информационными технологиями, я делал бы гораздо быстрее», — заметил президент и директор информационной службы компании Princess Cruise Lines Алан Бакелью.
А после построения корпоративной архитектуры на основе служб и событий Бакелью — или любой другой директор ИТ-службы — получит в свое распоряжение самую лучшую волшебную палочку, о которой только можно мечтать сегодня.
A New Blueprint For The Enterprise. CIO Magazine. March 1, 2005
Корпоративная архитектура при минимуме затрат
Вы хотите построить корпоративную архитектуру, но не имеете для этого достаточного количества денег или людские ресурсы? Тогда вам, наверное, будет интересно познакомиться с тем, как пытался решить данную задачу один из руководителей информационных служб.
Что же это такое? — восклицаете вы. Не можете позволить себе нанять шестерых корпоративных архитекторов? Не в состоянии убедить генерального директора ежемесячно принимать участие в заседаниях комитета по корпоративной архитектуре?
Построение корпоративной архитектуры при минимуме затрат предполагает отказ от большей части мероприятий по планированию и сосредоточение основных усилий на интеграции служб и повторно используемых компонентов. Кроме того, подразумевается оплата труда разработчиков, хорошо знающих Web-службы, и закупка промежуточного ПО, содержащего механизмы интеграции, которых так недостает Web-службам. У финансового директора появляется возможность сохранить в качестве основной ударной силы старые мэйнфреймы, но ему нужно приглядывать за тем, чтобы ИТ-служба обеспечивала быстрое и эффективное удовлетворение вновь возникающих потребностей.
У Дэйва Мэйвиса, директора ИТ-службы компании MasterBrands, специализирующейся на производстве мебели, нет своей команды, занимающейся построением корпоративной архитектуры, нет плана и нет соответствующего комитета. Зато у него имеется куча старых систем на базе мэйнфреймов, распределенных между 22 фабриками, - результат претворения в жизнь политики агрессивных приобретений. Мэйвис решил сэкономить деньги, сделав ставку на применение служб и промежуточного ПО. Новая архитектура призвана укрепить позиции уже имеющихся у него мэйнфреймов.
Мэйвис проанализировал бизнес-процессы всех фабрик, пытаясь отыскать нечто общее, допускающее совместное использование. В итоге он обнаружил две общие черты, связанные с порядком обработки заказов и оценкой состояния запасов. Применяя сочетание промежуточного ПО и Web-служб, корпоративный архитектор Мэйвиса (у него имелся один такой специалист) создал комбинированные приложения, осуществляющие управление отдельными компонентами бизнес-процессов примерно на трети фабрик. (В настоящее время архитектор работает над проектированием механизма, позволяющего управлять остальными компонентами.) Промежуточное ПО и Web-службы были использованы им и для повышения гибкости функционирования систем на базе мэйнфреймов. Промежуточное программное обеспечение извлекало заказы, накопленные в системах за время их вынужденного простоя, и пересылало соответствующие задания на погрузочную площадку.
«После того как мы отпускали грузовики, нередко выявлялось еще несколько заказов, поступивших уже после запуска процедуры упаковки, — пояснил Мэйвис. — Приходилось отправлять товар на следующее утро в практически пустом грузовике за дополнительные 85 долл. Теперь мы можем обрабатывать эти заказы и загружать товар в грузовик до того, как вечером он покинет территорию нашего предприятия».
Такой подход не вполне соответствует современному уровню развития технологий, но тем не менее представляет собой реально работающую архитектуру.
В отрыве от стратегии
В процессе построения корпоративной архитектуры гораздо важнее понимать структуру вашего бизнеса, а не его стратегию. Причем добиться этого можно даже без общения с генеральным директором.
Корпоративная архитектура представляет собой способ согласования информационных технологий со стратегией бизнеса. Но что если у вашей компании нет четкой стратегии? (Ведь стремление занять первую позицию на рынке нельзя назвать стратегией.)
«Понимание организации бизнеса — путей интеграции и стандартизации информации и процедур — поможет вам построить корпоративную архитектуру, отвечающую стратегическим потребностям компании независимо от их конкретного выражения», — подчеркнула главный аналитик Центра исследований информационной стратегии при Массачусетском технологическом институте Жанна Росс.
Давайте приведем несколько простых примеров. (Речь не идет о том, что в упоминаемых компаниях отсутствует ясная стратегия. Просто они настолько известны, что увязать процессы со стратегией не представляет никакой сложности.)
Любая посылка доставляется службой UPS в произвольную точку мира одинаковым образом (для всех процедур здесь характерна высокая степень стандартизации и интеграции), при этом жизненно важное значение имеет осведомленность сотрудников в штаб-квартире о текущем местонахождении посылок. (Соответственно и информация здесь тоже стандартизирована и интегрирована.) Таким образом, корпоративная архитектура UPS также является полностью централизованной и стандартизированной.
В компании McDonald?s все процедуры тоже стандартизированы (все бутерброды готовятся одинаково), однако сотрудникам в штаб-квартире вовсе не нужно знать, где находится каждый бутерброд в произвольный момент времени. В результате для корпоративной архитектуры McDonald?s характерна полная стандартизация компьютерной инфраструктуры внутри ресторанов и отсутствие информационной интеграции между ними.
Компания, занимающаяся предоставлением финансовых услуг, продает отдельные продукты с использованием различных процедур, однако возможность продажи разных продуктов одному и тому же клиенту предполагает необходимость стандартизации и интеграции информации (в отличие от процессов).
И наконец, компания, объединяющая множество независимых подразделений, не испытывает особой потребности в стандартизации процедур или информации. Деятельность компаний подобного рода лучше всего обслуживать, формируя корпоративную архитектуру на уровне отдельных бизнес-подразделений.
«Нас приучили ждать определения стратегии бизнеса и лишь затем приступать к построению отвечающей ее потребностям архитектуры ИТ», — заметила Росс.
Однако в реальном мире - в мире, где вам приходится работать, - стратегия, возможно, не будет определена никогда, а ИТ-служба, безусловно, не может позволить себе ждать.
Корпоративная архитектура нуждается в управлении
Поскольку корпоративная архитектура должна выстраиваться вокруг бизнеса (на практике так и происходит), вам следует продумать вопросы своего участия в основном бизнесе.
Работа группы проектирования корпоративной архитектуры наиболее эффективна, когда ее участники знают о бизнесе больше, чем менеджеры отдельных программных проектов. Следовательно, для построения механизма управления необходимы соответствующие знания.
В компании T-Mobile централизованная группа разработки корпоративной архитектуры разделена на четыре участка в соответствии с ключевыми технологиями компании.
Помимо четырех технологических участков здесь имеется и участок бизнеса. К работе на нем привлечены специалисты по стратегическому планированию, маркетингу и продажам. Данная бизнес-группа нацелена главным образом на разработку идей создания новых продуктов, которые можно было бы развернуть в рамках единой корпоративной архитектуры. Она отвечает за прочную связь между ИТ и стратегией бизнеса. А корпоративная архитектура является составной частью этой стратегии и никоим образом не отделена от нее.
В большинстве проектов построения корпоративных архитектур подобная связь отсутствует. «Неудивительно, что ее не было и в T-Mobile, когда мы только начинали заниматься всем этим, — заметил вице-президент компании T-Mobile International по технической стратегии Хоссейн Мойин. — Нужно понимать, для кого эта архитектура предназначена. В прошлом все наши усилия оказывались напрасными, потому что мы не вовлекали в этот процесс нужных людей».
Управление - вот верный способ добраться до нужных людей и сохранять связь с ними.
С чего начать
Некоторые образцы стандартов способны заставить вас задуматься о корпоративной архитектуре. Но не ждите, что сразу получите ответы на все свои вопросы. «Эти структуры представляют собой книжные полки, на которых расставляются документы, связанные с архитектурой», — пояснил Брюс Робертсон, вице-президент исследовательской компании Meta Group по вопросам корпоративного планирования и архитектуры.
- Одними из наиболее популярных — и к тому же бесплатными — являются структуры Open Group Architecture Framework (Togaf), www.opengroup.org/architecture/togaf
- Даже будучи разработанной специально для правительственных агентств США, структура Federal Enterprise Architecture Framework (FEAF) может пригодиться и частным компаниям, www.feapmo.gov
- Джон Захман, считающийся «отцом корпоративной архитектуры», предлагает бесплатный вариант собственной структуры, www.zifa.com/framework.html