Инфраструктуры информационных систем (ИС) грозят развалиться от собственной сложности. Они подобны аэропортам современных деловых центров - Нью-Йорка, Франкфурта или Токио.
Эти узлы транспортной инфраструктуры никогда не предназначались для сегодняшней интенсивности воздушного движения, для столь высокой сложности управления этим движением, в них не предусматривались современные требования к безопасности и нуждам парковки автотранспорта. Как результат эти аэропорты постоянно перестраиваются. Увы, это - унаследованные инфраструктуры!
То же верно и относительно практически каждого конгломерата информационных технологий (ИТ), сложившегося в больших организациях. Технологические платформы на современных предприятиях - это сложнейшее сочетание конструкций, устройств, стандартов, серверов, операционных систем, унаследованных систем и пакетов прикладных программ.
Как и в случае с аэропортами, компаниям предстоит жить с большей частью этого наследства непредсказуемо долго. Они будут добавлять к нему новые кусочки и заплатки. Они будут хвататься за любое средство, которое позволило бы увеличить совместимость и интеграцию: так, например, Internet наведет их на использование интрасети.
Но на некоторой стадии развития сложность технической базы превысит доступные предприятию возможности в профессиональной подготовке сотрудников и в управлении ИС. С точки зрения большинства пользователей, мы уже сейчас получаем ничтожно мало ценного от новых средств ИТ по сравнению с увеличением их стоимости и объема функций поддержки, с ростом числа процедур администрирования, отказов и точек ненадежности.
Не так давно директор информационной службы одной из ведущих нефтехимических компаний сетовал мне на то, что для него все разговоры о стратегии развития ИС - только фасад здания. На самом деле он полностью увяз в заботах о поддержке функционирования более чем 100 тыс. настольных компьютеров. Сегодня он с этим едва справляется и со страхом думает о лэптопах, сетевой мультимедиа, электронной коммерции, интранете с экстранетом, агентах и беспроводной связи, которые лишат его сотрудников каких-либо шансов справиться с ситуацией.
Для этого директора, так же как для его коллег из других больших компаний, развернуть на предприятии полностью новую инфраструктуру не легче, чем перестроить аэропорт имени Кеннеди в Нью-Йорке. Идеальным вариантом было бы снести этот аэропорт и на его месте построить новый, но на практике это невозможно. То же и с инфраструктурой ИС: ее лучше бы уничтожить, но унаследованные системы приходят к нам от других поколений организации бизнеса, технологии и прикладных систем. Таким образом, нужно думать о будущей архитектуре ИС уже сейчас и в соответствии с этим выбирать средства, которые помогут преодолеть ограничения наследуемых систем.
Вот мое мнение о принципах построения инфраструктур следующего поколения. Они должны отвечать таким критериям:
- Проектируйте инфраструктуру по принципу "от потребителя к компании". Она не должна базироваться на распространении функций "от компании к потребителю", как это делается сейчас. Это может, например, означать, что в основу проектирования следует положить простейший стандарт Web-браузера с минимальными возможностями, поскольку это будет связывать вас с наибольшим числом потребителей. (Естественно, это значит, что вы лишаетесь массы прелестей типа использования языка моделирования виртуальной реальности или мультимедиа.)
- Обеспечьте предельную простоту на стороне конечного пользователя. Простота должна быть во всем: в обучении, тестировании, установке и доступе к техподдержке. В этом отношении позорным примером служат Windows 95 и выросшая вокруг этой системы индустрия программного и аппаратного обеспечения. Они дают пользователю заведомо избыточную сложность и берут на себя заведомо недостаточную ответственность за разрешение проблем, ежедневно возникающих вследствие этой сложности.
- Уменьшайте разнообразие. Возможно, это звучит как ересь, однако управлять программной средой настольных компьютеров и одновременно многочисленными средствами для работы с хранилищами или витринами данных становится почти немыслимо. Я не вижу иного выхода, чем изъятие компаниями из употребления всяческих дополнительных аппаратных и программных возможностей; и делать это следует не столько ради стандартов, сколько в интересах выживания и сохранения рассудка сотрудников информационных служб и сообщества пользователей. Применительно к сетевой архитектуре, вероятно, сказанное означает принятие в качестве стандарта протокола IP.
- Сокращайте на всех уровнях требования к обучению и эксплуатации. Чем меньше нужно будет обучаться технологии пользователям или сотрудникам информационной службы, тем меньше пользователи будут нуждаться в поддержке этих сотрудников, а эти сотрудники - в поддержке поставщиков.
- Думайте о выполнении обязательств и обещаний, а не о функциональных возможностях. Обещания, которые дает большинство информационных служб, так же надежны, как и те, что мы слышим от авиакомпаний: "Мы постараемся доставить вас к месту назначения вовремя. Не исключено, что мы будем вынуждены отменить полет. Вы же понимаете, все может случиться". Архитектура ИС завтрашнего дня должна базироваться на твердых обещаниях и обязательствах: "То, что мы вам установим, будет работать. Мы гарантируем качество наших программ".
- Делегируйте работы внешним фирмам для того, чтобы упростить требования к вашему собственному персоналу и снять напряженность в управлении, чтобы избавиться от сложностей в сопровождении и архитектуре. Идите на это даже при сиюминутном увеличении расходов.
Большинство организаций, с которыми я имел дело, соблюдают перечисленные принципы простоты с точностью до наоборот. Их информационные службы работают все интенсивнее именно над увеличением сложности. Давайте остановимся. Политикой информационных служб должна стать простота, а не "высокая технология". Если эти службы будут оставаться источником сложности, генеральные директора найдут простое решение проблемы: делегировать внешним фирмам все их функции и упразднить сами службы.
Недавно в издательстве Harvard Business School Press вышла книга Питера Кина The Business Internet and Intranets. Автор доступен по адресу peter@peterkeen.com.