Воскресенье, 20.07.2025, 02:24

КИТ Инф. технологии

Категории раздела
Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0

Каталог файлов

Главная » Файлы » Мои файлы

Стратегическое планирование сетей масштаба предприятия
05.06.2017, 20:55

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

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

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

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

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

технологии предыдущих поколений. Такие системы называются унаследованными. С ними связаны следующие проблемы: (1) они не приспособлены к интеграции с системами нового поколения; (2) системы часто используются на морально устаревших аппаратно-программных платформах и не могут быть легко перенесены на новые платформы; (3) недоступны разработчики систем, а сами они написаны на старых и трудно постигаемых языках программирования (в частности, на языках ассемблера); (4) без этих систем организация не может существовать, причем не допускается даже временный выход из строя.

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

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

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

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

Так что основные проблемы могут быть связаны с портированием клиентских частей информационной системы и серверов приложений (а также Web-серверы, если система является Intranet-ориентированной и используется свободно доступный Web-сервер). Опять же, если покупается готовая информационная система или ее сборкой/разработкой занимается компания-интегратор, то условия возможности переноса должны быть точно оговорены в контракте (главное не забыть, что этот перенос может понадобиться).

Наиболее сложным, с одной стороны, и наиболее естественно решаемым является случай, когда организация сама занимается проектированием и разработкой информационной системы. Тогда прежде всего нужно решить, какая операционная система будет использоваться на клиентских местах. Если это какая-то разновидность ОС UNIX (что встречается все реже), то клиентская часть приложения должна разрабатываться с использованием некоторого мультиплатформенного средства разработки, опирающегося на стандарты этой ОС. Тогда с большой вероятностью особые проблемы при переносе не возникнут. Если же будет использоваться операционная система компании Microsoft (Windows 95 или NT), то с большой вероятностью аппаратной платформой клиентской 233

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

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

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

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

При проектировании корпоративной сети полезно ее представление в виде многослойной пирамиды. Хотя слои этой пирамиды связаны и оказывают непосредственное влияние друг на друга, обычно каждый слой проектируется достаточно автономно, специалистами и фирмами соответствующего профиля.

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

1.

Фирмы-производители или дистрибьюторы аппаратуры, выступающие в роли интеграторов. У этих интеграторов пирамида опирается на очень узкое основание из одной платформы от одного-двух производителей. Минусы и некоторые плюсы в работе такого интегратора достаточно очевидны.

2.

Фирмы, ориентирующиеся на одну из СУБД, например, только на Oracle или Informix. В этом случае узким местом пирамиды является середина: при попытке использовать несколько аппаратных платформ и широкий спектр прикладного программного обеспечения, ограничения диктуются используемой СУБД.

3.

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

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

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

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

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

Сейчас каждый сетевой интегратор выполняет проекты согласно своим собственным представлениям о рациональной организации труда, и методика проектирования каждой фирмы является неким "ноу-хау". Тем не менее, с учетом более богатого (но, может быть, не всегда нам подходящего) западного опыта можно сформулировать некоторые типовые этапы выполнения сетевых проектов:

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

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

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

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

Установка и наладка системы. Данный этап подразумевает координирование поставок от субподрядчиков, управление конфигурированием, инсталляцию и наладку оборудования, обучение персонала.

235

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

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

Для каждого из упомянутых этапов и даже для отдельных более мелких задач может быть разработано техническое задание. Постановка задачи зависит от того, какую часть работы решено отдать внешнему интегратору, а какую часть - выполнить своими силами. Этот этап тесно связан с этапами выбора интегратора и заключения с ним контракта.

10.1.2. Роль системных интеграторов

Задачи системного интегратора могут меняться в зависимости от условий контракта, в наиболее же общей форме в его обязанности входят следующие:

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

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

Координация работы всех поставщиков оборудования и программного обеспечения.

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

10.2. Этапы проектирования корпоративных сетей

10.2.1. Анализ требований

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

236

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

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

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

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

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

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

обосновать перед руководством предприятия необходимость покупок;

написать эффективное техническое задание;

определить критерии для оценки качества сети.

Различные компании выполняют анализ требований к сети различными способами с различной степенью детализации в соответствии с традициями предприятия и его технической политикой. Документ, описывающий требования к сети, может быть объемом от 10 до 150 страниц. Некоторые предприятия выполняют такой анализ сами. Другие предприятия прибегают к помощи консультантов или системных интеграторов. Это делается в тех случаях, когда персонал отдела автоматизации не имеет достаточного опыта в проектировании и установке сетей. Кроме того, использование независимых консультантов или системных интеграторов в силу их объективности поможет взглянуть по-новому на проблемы и на их решения.

10.2.2. Построение функциональной модели производства 237

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

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

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

Для разработки бизнес-модели необходимо собрать бригаду, состоящую из руководителей отделов, ведущих специалистов и сотрудников отдела автоматизации. Обратите внимание на следующие моменты:

необходимо назначить руководителя работы;

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

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

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

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

Категория: Мои файлы | Добавил: BSG
Просмотров: 311 | Загрузок: 0 | Рейтинг: 0.0/0
Всего комментариев: 0
Имя *:
Email *:
Код *: