Корпоративные сети

интеграции неоднородных информационных ресурсов являются актуальными для

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

В заключение данного раздела курса повторим, что приведенная классификация

методов и технологий не является полностью ортогональной. В реальной жизни

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

решений. Наша цель не состоит в том, чтобы выдать готовые рецепты

построения информационной системы. Мы стремимся погрузить слушателей в мир

информационных технологий с тем, чтобы в дальнейшем было проще

ориентироваться в этом мире и понимать значение его сущностей.

9.4. Проблемы проектирования и разработки приложений

В этом разделе мы кратко обсудим проблемы построения информационных

приложений, которые, с одной стороны, примыкают к чисто техническим

проблемам, а с другой стороны, тес- но связаны с проблемами

организационными. Отметим, что в данном разделе многое является спорным и

отражает личную точку зрения автора (которая совпадает с точкой зрения

многих авторитетных специалистов).

9.4.1. Как правильно оценить текущие и будущие потребности организации

На самом деле, это является одной из наиболее сложных задач. Недооценка

потребностей приводит к размножению мелких информационных систем,

обеспечивающих отдельные информационные нужды предприятий (например,

бухгалтерия, складское хозяйство, отдел кадров, служба маркетинга и т.д.).

В дальнейшем может оказаться, что эти системы частично дублируют одна

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

информационных систем, построенных на разных технологиях, - это и источник

"унаследован- ных" систем. Переоценка потребностей может привести к

созданию чрезмерно масштабной системы с неразумным расходованием средств и

потребностью в квалифицированном штате администраторов.

Самое главное, что здесь невозможны общие рекомендации. Руководители

организации обладают (или, по крайней мере, должны обладать) развитой

интуицией относительно перспектив развития. Сторонние компании-интеграторы

имеют больший опыт создания информационных систем, могут лучше оценить

доступность недорогих и эффективных решений.

9.4.2. Как выбрать базовые аппаратно-программные средства, чтобы не

потратить слишком много денег и не ограничить будущее развитие приложения

Естественно, что требования к аппаратно-программным средствам определяются

требованиями к информационной системе в целом. Какие бы информационные

возможности не требовались служащим корпорации, окончательное решение

всегда принимается ее руководством, которое корректирует требования к

информационной системе и формирует окончательное представление об

аппаратной среде (что является исходной точкой и проектов, выполняемых

сторонними интеграторами). На наш взгляд, имеются четыре возможных позиции

руководства по поводу места информационной системы в корпорации:

пессимистическая, пессимистически-оптимистическая, оптимистически-

пессимистическая и оптимистическая.

Руководитель-пессимист рассуждает следующим образом. Корпорации нужно

продержаться хотя бы какое-то время. Без информационной системы это

невозможно. Нужно выбрать самое дешевое решение, которое может быть

реализовано максимально быстро. Руководитель не думает, что будет с

корпорацией через два года (вернее, поскольку он пессимист, то думает, что,

скорее всего, через два года корпорация просто не будет существовать или у

нее сменится руководитель). При такой позиции наиболее подходящим является

некоторое закрытое и законченное техническое решение. Например, это может

быть полностью сбалансированная локальная сеть Novell с выделенным файл-

сервером и фиксированным числом рабочих станций. Жесткость решения затем

закрепляется соответствующим программным обеспечением информационной

системы. Возможности расширения системы отсутствуют, реинжиниринг требует

практически полной переделки системы.

Пессимистически-оптимистический руководитель не ожидает краха корпорации

или своего собственного увольнения. Но он не надеется на изменение статуса

компании, например, на появление зарубежных филиалов. Возможно, корпорация

будет несколько развиваться, возможно, появятся новые виды бизнеса,

возможно, увеличится число служащих. Но поскольку руководитель все-таки

более пессимист, чем оптимист, то он не очень высоко оценивает шансы на

развитие (дай-то Бог, чтобы за два года мы выросли на 20%). Такой позиции

руководства больше всего подходит закрытое решение, обладающее

ограниченными возможностями расширения. Например, это может быть локальная

сеть Novell, в которой пропускная способность превосходит потребности

имеющихся рабочих станций, а файл-сервер может быть оснащен дополнительными

магнитными дисками. Если пессимизм руководителя окажется неоправданным, то

корпорация встретится с потребностью сложного реинжиниринга.

Руководитель с оптимистически-пессимистической позицией ставит своей целью

развитие корпорации. Он учитывает, что при развитии корпорации потребуется

соответствующее развитие информационной системы, для чего, вообще говоря,

может понадобиться сменить сервер баз данных. Он учитывает, что при

развитии корпорации могут образоваться территориально разнесенные офисы, в

результате чего, возможно, потребуется перейти к использованию

распределенной базы данных. Он учитывает, в конце концов, что корпорации

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

филиалами и/или партнерами. Пессимизм руководителя состоит только в том,

что он заранее делает ставку на одного производителя (эти-то продукты я

знаю). Например, может быть сделана установка на использование только Intel-

платформ в среде Microsoft или только Alpha-платформ с VAX/VMS. Вообще

говоря, это здоровый пессимизм, поскольку однородность аппаратно-

программной среды существенно облегчает ее администрирование. Но как обидно

будет этому руководителю, если ему предложат дешево купить прекрасный

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

снова производить изнурительный реинжиниринг.

Наконец, руководитель-оптимист разделяет позицию оптимистически-

пессимистического руководителя по поводу перспектив развития корпорации, но

при этом желает сохранить возможность использования различных аппаратных

платформ. Он стимулирует построение открытой корпоративной информационной

системы, которая может неограниченно наращиваться за счет подключения новых

сегментов сети, включения новых серверов и рабочих станций. Оптимистический

подход, естественно, требует применения международных стандартов, что

облегчает комплексирование аппаратного комплекса и обеспечивает реальное

масштабирование информационной системы. Если начать построение

корпоративной системы с сети Ethernet с использованием стека протоколов

TCP/IP, то это начало оптимистического решения. В этом случае проблемы

реинжиниринга практически отсутствуют (пока не сменятся стандарты).

Конечно, приведенная классификация является несколько утрированной. В жизни

все гораздо сложнее. В частности, нельзя не учитывать влияние на

руководителя технических специалистов. Чем грамотнее составляется

обоснование на приобретение технических средств, тем обоснованнее оптимизм

или пессимизм руководителя. Конечно, многое определяется возможными

денежными затратами. Но стоит заметить, что оптимистический подход (по сути

дела, это подход открытых систем) требует минимальных затрат на начальном

этапе становления корпоративной системы (если, конечно, не учитывать

необходимость приобретения хорошего программного сервера баз данных).

Главный вывод этого пункта состоит в том, что выбор технических средств для

построения корпоративной информационной системы - это непростая задача,

включающая технические, политические и эмоциональные аспекты. Ни в коем

случае комплексирование аппаратуры нельзя пускать на самотек. Простой

пример. Многие считают, что чем больше тактовая частота аппаратного сервера

баз данных, то тем быстрее будет работать СУБД. Вообще говоря, это

неправильно. Быстродействие любого сервера баз данных в основном

определяется объемом основной памяти и/или числом процессоров. Другими

словами, с одинаковой тщательностью нужно относиться и к выбору общей

аппаратной архитектуры системы, и к выбору конфигурации каждого из ее

компонентов.

9.4.3. Какие этапы разработки проекта приложения являются наиболее

дорогостоящими и почему

Это в большой степени зависит от масштабности проекта и вида проектируемого

информационного приложения. Например, если используется традиционная

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

баз данных, то, по всей видимости, самой дорогой частью проекта будет

проект базы данных. И понятно, почему. Во-первых, для проектирования

сложной базы данных трудно обойтись без дорогостоящей системы автоматизации

проектирования (CASE-системы). Во-вторых, корректность схемы базы данных и

правильность ее построения являются залогом работоспособности и

эффективности будущей информационной системы. Поэтому к проектированию базы

данных должны применяться максимальные усилия.

Если же по архитектурным соображениям выбирается многозвенная архитектура

"клиент-сервер" с несколькими серверами баз данных и серверами приложений,

работающими под управлением общего монитора распределенных транзакций, то

трудоемкость проекта несколько перераспределяется. Конечно, по-прежнему

критично важен проект (распределенной) базы данных. Но не менее важно

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

применяться репликация и т.д.

Для организации прикладной системы оперативной аналитической обработки

информации, основанной на использовании склада данных, наибольшие накладные

расходы требуются именно на организацию склада данных, включая механизмы

источников данных, очистки и согласования данных, возможности многомерного

представления информации и т.д.

9.4.4. Что такое "унаследованная система" (legacysystem) и как поступить с

этим "наследством"

Особенно трудно создавать современную высокотехнологичную информационную

систему в организации, где уже используются информационные системы,

основанные на технологии предыдущих поколений. Такие системы называются

унаследованными. С ними связаны следующие проблемы: (1) они не

приспособлены к интеграции с системами нового поколения; (2) системы часто

используются на морально устаревших аппаратно-программных платформах и не

могут быть легко перенесены на новые платформы; (3) недоступны разработчики

систем, а сами они написаны на старых и трудно постигаемых языках

программирования (в частности, на языках ассемблера); (4) без этих систем

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

выход из строя.

Отмеченные проблемы кажутся настолько сложными и противоречивыми, что

первым является желание закрыть на них глаза. Собственно, так многие и

делают. Пока унаследованная система работает, пускай работает, а когда

перестанет функционировать, тогда и подумаем, что делать. Решение простое,

но очень ненадежное. Известны примеры, когда мультимиллиардные компании

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

Так что же делать? Прежде всего нужно оценить важность унаследованной

системы для организации. Если окажется, что некоторое время без нее можно

обойтись, то самым дешевым решением будет воспроизводство системы на новой

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

остановка функционирования системы недопустима, то при проектировании

нового поколения информационной системы предприятия потребуется применять

некоторую промежуточную технологию типа той, которую мы уже упоминали.

9.4.5. Как перенести существующее приложение на другую аппаратно-

программную платформу

Конечно, возможность подобного переноса должна быть предусмотрена при

первоначальной разработке приложения. Очевидно, что без участия компании-

разработчика или ее ответственного представителя невозможно произвести

перенос сервера баз данных. Обычно крупные платформы для своих заказчиков

оказывают услугу по поставке аналогичного или усовершенствованного продукта

для другой платформы (естественно, не бесплатно, но существенно дешевле,

чем обошлась бы покупка полностью заново).

Так что основные проблемы могут быть связаны с портированием клиентских

частей информационной системы и серверов приложений (а также Web-серверы,

если система является Intranet-ориентированной и используется свободно

доступный Web-сервер). Опять же, если покупается готовая информационная

система или ее сборкой/разработкой занимается компания-интегратор, то

условия возможности переноса должны быть точно оговорены в контракте

(главное не забыть, что этот перенос может понадобиться).

Наиболее сложным, с одной стороны, и наиболее естественно решаемым является

случай, когда организация сама занимается проектированием и разработкой

информационной системы. Тогда прежде всего нужно решить, какая операционная

система будет использоваться на клиентских местах. Если это какая-то

разновидность ОС UNIX (что встречается все реже), то клиентская часть

приложения должна разрабатываться с использованием некоторого

мультиплатформенного средства разработки, опирающегося на стандарты этой

ОС. Тогда с большой вероятностью особые проблемы при переносе не возникнут.

Если же будет использоваться операционная система компании Microsoft

(Windows 95 или NT), то с большой вероятностью аппаратной платформой

клиентской части будет Intel, и проблемы с переносом могут проявиться при

смене версии операционной системы. Аналогичные соображения применимы к

серверам приложений.

10. Проектирование корпоративных сетей

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

Прежде всего, это методология проектирования, то есть последовательность и

содержание работ, которые необходимо выполнить при создании или

модернизации корпоративной сети. Далее рассматривается проблема выбора

средств анализа работы сети, без которых трудно сформулировать требования к

проектируемой сети, провести натурные эксперименты на пилотной сети и,

наконец, провести приемно-сдаточные испытания новой только что

спроектированной сети. Следующую группу проблем, рассматриваемых в данном

разделе, составляют вопросы взаимодействия заказчика с интегратором.

10.1. Особенности проектирования корпоративных сетей

При проектировании корпоративной сети полезно ее представление в виде

многослойной пирамиды. Хотя слои этой пирамиды связаны и оказывают

непосредственное влияние друг на друга, обычно каждый слой проектируется

достаточно автономно, специалистами и фирмами соответствующего профиля.

В зависимости от направления движения по этой пирамиде: сверху вниз - от

бизнес-приложений к аппаратной платформе, или снизу вверх - от аппаратуры к

приложениям, или от середины - от конкретной СУБД, - все фирмы, работающие

в области сетевой интеграции, можно условно разделить на три группы:

1. Фирмы-производители или дистрибьюторы аппаратуры, выступающие в роли

интеграторов. У этих интеграторов пирамида опирается на очень узкое

основание из одной платформы от одного-двух производителей. Минусы и

некоторые плюсы в работе такого интегратора достаточно очевидны.

2. Фирмы, ориентирующиеся на одну из СУБД, например, только на Oracle или

Informix. В этом случае узким местом пирамиды является середина: при

попытке использовать несколько аппаратных платформ и широкий спектр

прикладного программного обеспечения, ограничения диктуются

используемой СУБД.

3. Наконец, третья группа - независимые интеграторы, которые могут

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

нельзя уличить в особой привязанности к определенной платформе,

сетевым конфигурациям или приложениям. У таких интеграторов

единственным критерием выбора каждого конкретного решения в идеале

является требование достижения максимального эффекта в рамках заданных

ресурсов. В таком случае есть возможность гибко строить любые

конфигурации, что позволяет достаточно просто решать проблемы,

связанные с тем, что заказчик уже использует, например, какую-либо

СУБД и не хочет переучивать свой персонал для работы с другой базой

данных.

При этом, при проектировании какого-либо слоя характеристики других слоев,

оказывающих влияние на принятие проектных решений, берутся в виде исходных

данных, чаще всего в весьма обобщенном виде. Например, при проектировании

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

коммуникационное оборудование вполне определенного диапазона стоимости -

того диапазона, который имеется в распоряжении предприятия. И наоборот,

разработчики транспортной системы ориентируются на усредненные данные о

трафике, который могут создать имеющиеся на предприятии приложения и те

приложения, которые намечено ввести в действие в ближайшие год-два.

10.1.1. Этапы проектирования

Следует оговориться, что рассматриваемые в этом разделе вопросы методологии

проектирования часто не вполне соответствуют существующей сейчас практике

реализации проектов фирмами-интеграторами. Нельзя однозначно сказать,

насколько это хорошо или плохо, но одновременно с произошедшими за

последние пять лет изменениями отношений собственности и глубокой

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

проектных работ, включавшая в себя следование строго регламентированному

перечню этапов, непременное сопровождение каждого этапа стандартной

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

актов "приемно-сдаточных испытаний ".

Сейчас каждый сетевой интегратор выполняет проекты согласно своим

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

проектирования каждой фирмы является неким "ноу-хау". Тем не менее, с

учетом более богатого (но, может быть, не всегда нам подходящего) западного

опыта можно сформулировать некоторые типовые этапы выполнения сетевых

проектов:

Анализ требований. На этом этапе формулируются основные деловые цели

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29