Архитектура: новейшие разработки предполагают возврат к основам с требованием обеспечения высокой гибкости
Читатель узнает:
  • почему сейчас самый подходящий момент для переосмысления архитектуры предприятия;
  • где ваша архитектура должна быть тверда и где она может гнуться;
  • стратегии достижения широких перспектив.

Недавно архитектура предприятия проигрывала во всем: громоздкая, неповоротливая, негибкая и почти всегда опаздывающая. Проблемы архитектуры даже не обсуждались во время продолжавшейся три года шумихи вокруг «Проблемы 2000», биржи NASDAQ и буквы «е». Тем временем архитектура не стояла на месте. И когда технологический бум закончился, опустошенная корпоративная Америка обнаружила, что архитектура изменилась и стала гораздо более привлекательной.

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

Подобная структура для некоторых директоров информационных служб может показаться легкомысленной, но не для Дэвида Уотсона, многоопытного ИТ-руководителя, который работал в качестве корпоративного вице-президента по технологии в нескольких компаниях, входящих в рейтинг 500 крупнейших компаний журнала Fortune. Уотсон жестко контролирует выбор IP протоколов, сетевых операционных систем, а также кабельной системы, предоставляя при этом некоторую свободу при выборе баз данных/аппаратного обеспечения/ОС. Такой подход позволяет поддерживать широкий спектр бизнес-приложений.

« Мы достаточно жестки на нижнем уровне архитектуры, и это позволяет нам быть более гибкими на верхних, - подчеркивает Уотсон, являющийся на данный момент ДИС компании Enfrastructure (шт. Калифорния). - У вас должна быть архитектура, и она должна быть гибкой, при этом некоторые части должны быть менее подвижны, чем другие».

Сохранение широких рамок

«Если в последние пару лет архитектура предприятия и создала себе плохую репутацию среди деловых пользователей, то это было вполне заслуженно, - считает Питер Вэйлл, директор исследовательского центра по информационным системам в МТИ (Кембридж). - Архитектура рассматривалась только как проблема стандартов на техническом уровне. Передовой опыт в ИТ привел директоров информационных служб к принятию подхода «ко всем с одной меркой», который является неправильным». Безусловно, архитектура должна определяться передовым опытом, отмечает Вэйлл, но в бизнесе, а не в информационной технологии.

Уотсон, например, считает, что следует сконцентрировать внимание и ресурсы на проблемно-ориентированных приложениях, иногда специально доработанных для использования конкретными подразделениями. При этом необходимо использовать передовые фронтальные (front-end) технологии, заказную XML-разработку, а также Web-средства для придания открытости системам. «Решение о выборе конкретного приложения должно всегда определяться потребностями бизнеса, - отмечает Уотсон, - и если кто-то предлагает вариант, требующий нового уровня технической поддержки, вы должны иметь возможность реализовать его».

Для создания такой возможности имеет смысл стандартизировать основные средства связи, используемые на всем предприятии, - электронную почту, голосовую почту, сетевое программное обеспечение, офисные приложения, операционные системы и браузеры, считает Уотсон. На этом уровне инфраструктура компании должна быть тверда как скала. «Это то основание, на котором закладывается ваша эффективность. Это та часть, которая обеспечивает согласованность в работе всего предприятия», - говорит он.

В современной открытой и разнородной архитектурной среде опасность загнать себя в угол минимизирована.

- Рой Свэкхамер, ДИС, CNF

Эндрю Винер, ДИС компании Myers Industries, a rubber and plastics, производитель из Акрона (шт. Огайо), соглашается, что имеет смысл обращать больше внимания на прикладные программы высокого уровня и уделять особое внимание этому направлению. «Мы гораздо более озабочены прикладными программами, чем архитектурой низкого уровня», - отмечает он. Винер считает, что перечень продуктов, утвержденных Myers Industries, является более широким по сравнению с традиционным стандартизированным набором. «Мы пытаемся отобрать те продукты, в использовании которых у нас есть некоторый опыт, но наш список весьма обширен. Природа открытой архитектуры позволяет вам быть гибкими».

Правильный выбор времени

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

Там, где раньше каждая «норовистая» СУБД или «самодельная» программа электронной почты грозила возникновением нескончаемых проблем, сейчас большинство программ при некоторой настройке совместимы (безусловно, при наличии серьезно подготовленной базовой инфраструктуры). «Наибольший интерес для нас сейчас представляет интеграция между приложениями, - говорит Билл Россер, вице-президент и директор по исследованиям аналитической компании GartnerGroup, (шт. Коннектикут). - Мы проводим целые конференции, посвященные только этой теме».

Более высокая степень интероперабельности означает, что компании могут не демонтировать приемлемые в других отношениях унаследованные системы, для того чтобы обеспечить совместимость приложений. «У нас есть много различных приложений и серьезные основания для того, чтобы иметь их все. Главное - все приложения вместе работают, - говорит Рой Свэкхамер, ДИС холдинга CNF (шт. Калифорния). - В современной открытой и разнородной архитектурной среде опасность загнать себя в угол минимизирована».

Быстрое распространение Web-интерфейса в корпоративной Америке, позволяет компаниям связать приложения на верхнем уровне. К примеру, Myers Industries приняла стандарты на основе системы ИТ-управления предприятием CA Unicenter компании Computer Associates и использует инструмент Bizworks этой же компании для достижения взаимодействия на уровне Web. «Мы пытаемся как можно больше развиться на корпоративном уровне, - говорит Винер. - Web позволяет нам построить оболочку, лежащую поверх всех наших приложений, и установить связь с приложениями через эту оболочку.»

Что раскачивается, что остается на месте?

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

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

Наиболее осторожно к исключениям относится, например, такая компания, как Johns Manville International (Денвер), где ДИС Чан Поллок тратит значительные ресурсы для развития и поддержания архитектуры предприятия. Два выделенных работника поддерживают и обновляют разнообразные стандарты, которые рассматриваются и утверждаются руководителями по развитию бизнеса, а затем публикуются через интранет компании для общего ознакомления. Благодаря такому вниманию Поллок и его команда надеются, что число исключений будет поддерживаться на минимальном уровне.

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

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

Уотсон из компании Enfrastructure придерживается средней позиции между кнутом и пряником. С одной стороны, он первый, кто осознает тот факт, что изменение технологии может потребовать довольно серьезных отклонений от генерального плана, но признает, что при хорошо построенной архитектуре это вполне реализуемо. «Internet является лучшим примером», - отмечает он. С другой стороны, Уотсон, как и Свэкхамер, настаивает на том, что, прежде чем получить одобрение на отход от сложившегося плана архитектуры, сторонники отклонений должны произвести расчеты и продемонстрировать результаты. «Я советую им подумать о способах достижения того, что они хотят, используя существующую архитектуру, - говорит он. - Однако, если они по-прежнему настаивают, то должны использовать стандартную пятилетнюю модель финансирования, чтобы воплотить свой план».

Сократ и деловая ценность

Уотсон и Свэкхамер не единственные, кто обращается к калькулятору, когда наступают трудные времена. Несомненно, бизнес-пользователи и руководители ИТ также должны активизировать свои бухгалтерские способности, когда они договариваются о предстоящих инвестициях в технологии. «Не далее как в следующем году мы рассчитываем увидеть архитектуру, основанную строго на цифрах», - говорит Бэрри Ловалво, технический директор Armeta Financial (Даллас). «В настоящее время сотрудники финансового отдела работают не покладая рук. «Что же мы здесь насчитали?» - повторяют они, проверяя ошибки в расчетах».

Не далее как в следующем году мы рассчитываем увидеть архитектуру, основанную строго на цифрах.

- Бэрри Ловалво, технический директор, Armeta Financial

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

«Я начинаю с того, что спрашиваю о бизнес-потребностях, которые не могут быть реализованы с помощью имеющейся архитектуры, - рассказывает Уотсон. - Если кто-то говорит, что продажи через Internet предпочтительнее традиционных, то мы не останавливаем его. Мы говорим, что это интересное деловое предложение; мы можем использовать его и посмотреть, к чему оно приведет».

Подобный диалог не является случайным дополнением к архитектуре. Такая возможность должна быть заложена в самой архитектуре, говорит Ричард Бушанан, вице-президент по стратегиям корпоративной архитектуры Meta Group, исследовательской компании в Стэмфорде (шт. Коннектикут). «Архитектура не вещь; это процесс. Архитектурная команда - это слуги логики, описывающей ценность любых инвестиций в терминах бизнес-стратегии».

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

«Когда кто-то заявляет, что ему требуется новая прикладная программа или инфраструктурная возможность, вы должны провести с ним дискуссию в стиле диалогов Сократа, - говорит Бушанан. - Они должны рассказать все: мне нужно данное приложение, потому что мне нужна такая-то информация, потому что мне необходимо обеспечить определенную бизнес стратегию, потому что иначе наши бизнес-цели не могут быть достигнуты».

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

Трейси Мэйор - независимый писатель, ей можно написать по адресу tmayor@mediaone.net.

Рассчитывая на перспективу

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

  • ОТКРЫТЬ КАНАЛЫ ОБЩЕНИЯ. В Myers Industries, работники информационных служб, отвечающие за архитектуру, встречаются с командой АСУ (MIS) каждый квартал для устранения противоречий, возникающих на ранних этапах. Для обеспечения целостности представления о задачах корпорации на встречу с управленцами АСУ на персональной основе приглашаются генеральные менеджеры компании.
  • ОПРЕДЕЛИТЬ ПРИОРИТЕТЫ. "На что пора обратить внимание? Вопросы маркетинга? Совместное использование? Низкозатратное владение? - спрашивает Билл Россер, Вице-президент и директор по исследованиям в GartnerGroup.- Вы должны четко представлять себе преимущества вашей архитектуры и как ваши потребности могут измениться до того, как вы воплотите что-либо в камне".
  • ПОСТРОИТЬ СИСТЕМУ СОВМЕСТНОЙ РАБОТЫ. Дэвид Уотсон, ДИС компании Enfrastructure, рекомендует связать с каждой бизнес-функцией как минимум одного ИТ-менеджера для того, чтобы наилучшим образом разъяснить преимущества архитектуры.
  • ПРЕДОСТАВИТЬ ДОСТАТОЧНОЕ ЧИСЛО СОТРУДНИКОВ. Если вы действительно хотите, чтобы ваша архитектура не стала очередной мертвой идеей, то она должна постоянно поддерживаться и подстраиваться. Например, компания Johns Manville International, производитель строительных материалов, выделяет двух сотрудников для обслуживания архитектуры.
  • НЕ УСЛОЖНЯЙТЕ. БУДЬТЕ КРАТКИ. "Соблазн заключается в том, чтобы представлять каждое распоряжение на 50 страницах. Но людям нужен стандартный набор правил - одна или две страницы!" - подчеркивает Бэрри Ловалво, технический директор в компании Armeta Financial (Даллас).
  • ЧЕТКО ОБЪЯСНЯЙТЕ ПОСЛЕДСТВИЯ. "Мы напряженно работаем, объясняя людям, что и зачем нам нужно знать, - говорит Эндрю Винер, ДИС компании Myers Industries. - Например, мы говорим, что если будем согласовывать наши действия, то сможем поддерживать сервер через удаленный доступ. Но если вы приобретете нечто, что будет плохо совместимо с нашим сервером, то понадобится три недели для того, чтобы мы смогли помочь вам."

Архитектура: да и нет

Бэрри Ловалво, технический директор (CTO) компании Armeta Financial, может предложить совет тем, кто строит архитектуру. Вот то, к чему он пришел.

  • Откажитесь от стремления к геройству. Исполнительная дирекция будет довольна, если вы объявите, что смогли сократить расходы и сэкономить x миллионов долларов, но эта одноразовая акция может нарушить ваши стратегические планы по развитию технологии на несколько лет вперед. Например, отказ сейчас от запланированного обновления аппаратного обеспечения, возможно, сэкономит вам в течение короткого периода некоторую сумму, но может привести к серьезному кризису по обслуживанию клиентов уже 18 месяцев спустя.
  • Внесите ясность. Медленное продвижение может привести к тому, что вы увязнете в мелочах, причем существует риск потерять уважение ваших "темпераментных звезд технологии" и вызвать сопротивление "автономных республик", таких как подразделения удаленных продаж. Чем более рационально и просто вы описываете свою задачу, тем скорее вы придете к согласию.
  • Сохраняйте перспективу. Текущий бизнес-цикл может быть не так привлекателен, как предыдущий, но это всего лишь бизнес-цикл, который когда-то должен закончиться.
  • Не выбирайте продукты исходя из трудных обстоятельств. Когда существуют ограничения в финансах, компании стремятся придерживаться технологий, в которые уже вложили большие средства, но это может быть ошибкой. Возможно, вы используете три различные сетевые операционные системы, но одна из них, поддерживающая 70% ваших систем, может быть наименее приспособлена к вашим потребностям в будущем. Возьмите на себя смелость, оцените возможности и затраты, и выберите наиболее функциональную на долгое время.