Файл: Учебное пособие по дисциплине итинфраструктура предприятия (курс лекций) Направление подготовки 38. 03. 05 Бизнесинформатика.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 406
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
163
•
Разработка философии развития ИТ в компании и определение места ИТ-подразделений в структуре предприятия.
•
Разработка требований к ИТ с позиций бизнес-стратегии.
•
Разработка оценок качества и целевых показателей работы ИТ- системы.
•
Определение альтернативных вариантов развитая ИТ и анализ возможных рисков.
•
Определение базовых принципов и направлений развития ИТ.
•
Определение основных направлений совершенствования про- цессов управления ИТ.
•
Определение интегральных характеристик ИТ-бюджета.
•
Определение списка проектов, необходимых для реализации
ИТ-стратегии, их последовательности и сроков.
•
Определение типовых способов реализации проектов (исполь- зование услуг сторонних компаний, аутсорсинг, выполнение работ силами собственного подразделения и np.).
•
Определение способов поддержки основных ИТ-сервисов (тра- диционный, SLA).
•
Эскизная разработка ИТ-архитектуры на ближайшую перспек- тиву, включая архитектуру приложений и технологическую архитектуру.
•
Эскизная разработка ИТ-архитектуры на долгосрочную пер- спективу, включая архитектуру приложений и технологическую архитек- туру.
•
Разработка архитектуры приложений.
В настоящее время для разработки архитектуры приложений исполь- зуются два подхода:
• Разработка архитектуры на основе интеграции приложений (кон- цепция Enterprise Application Integration - EAI).
• Разработка сервисо-ориентированной архитектуры (Service
Oriented Architecture - SOA).
SOA - это новая парадигма проектирования распределенных интег- рированных систем. Согласно SOA любые части информационных сис- тем, имеющие функциональность, рассматриваются как службы (service providers, провайдеры служб), которые предоставляют свою функцио- нальность другим частям системы посредством обмена сообщениями.
Сервисы обеспечивают бизнес-логику и средства управления состояния- ми, относящиеся к проблеме, для решения которой они предназначены.
В связи с тем, что поставщики корпоративных приложений ещё только ведут работы по переведу своих продуктов на SOA, а пока все большие продукты поставляются в виде монолитных корпоративных при- ложений, возможны различные варианты рассматриваемой услуги:
164
Разработка архитектуры на основе концепции EAI, что в настоящее время больше применимо при построении системы на основе готовых су- ществующих приложений.
Разработка сервисо-ориентированной архитектуры (SOA), что в на- стоящее время больше применимо при построении системы на основе за- казных разработок или при внедрении продуктов, уже построенных на ос- нове принципов SOA.
Разработка сервисо-ориентированной архитектуры (SOA) с преобра- зованием используемых унаследованных приложений к SOA. 6 этом слу- чае процесс разработки самой архитектуры аналогичен предыдущему ва- рианту, поэтому мы рассмотрим только этап преобразования используе- мых унаследованных приложений к SOA.
Разработка архитектуры приложений на основе концепции EAI
Разработка сервисо-ориентированной архитектуры (SOA), что в на- стоящее время больше применимо при построении системы на основе за- казных разработок или при внедрении продукте®, уже построенных на основе принципов SOA.
Разработка сервисо-ориентированной архитектуры (SOA) с преобра- зованием используемых унаследованных приложений к SOA. В этом слу- чае процесс разработки самой архитектуры аналогичен предыдущему варианту' поэтому мы рассмотрим только этап преобразования исполь- зуемых унаследованных приложений к SOA.
Разработка архитектуры приложений на основе концепции EAI
Очень укрупнено, методику разработки архитектуры приложений на основе концепции EAI, в случае, когда осуществляется полное перепроек- тирование, можно представить следующим образом:
• Обследование предприятия, определение основных функциональ- ных требований к приложениям,
• Выбор базового полнофункционального пакета, удовлетворяющего сформулированным требованиям.
• Проектирование методов интеграции выбранной на этапе 2 базовой системы с уже используемыми унаследованными системами, оценка за- трат на интеграцию.
• Определение типов дополнительных систем, которые необходимо будет дополнительно внедрить, чтобы полностью удовлетворить потреб- ности, выявленные на первом шаге. Выбор этих систем.
• Проектирование методов интеграции выбранной на этапе 2 базовой системы с дополнительными системами, определёнными на этапе 4, оцен- ка затрат на интеграцию.
•
Если затраты (сроки, деньги) на интеграцию сопоставимы с за- тратами на внедрение более тяжёлого пакета, необходимо вернуться на этап 2, повторив процесс выбора с анализом более тяжелых систем.
165
•
Определение последовательности внедрения модулей выбран- ной комплексной системы, внедрения дополнительных систем и интегра- ции с уже используемыми системами.
•
Разработка требований к технологической архитектуре на ос- нове разработанной архитектуры приложений.
•
В тех случаях, когда базовый пакет заранее предопределён, или даже уже частично внедрён и не подлежит замене, может проводиться не- полный комплекс работ по уточнению или развитию имеющейся архитек- туры приложений (этапы 3,4,5,7 или некоторые из них).
Разработка сервисо-ориентированной архитектуры приложений
(SOA)
В процессе проектирования сервисо-ориентированной архитектуры приложений в первую очередь должно быть разработано концептуальное представление. В ходе его разработки должны быть определены:
• Сервисы. При проектировании сервисов основная задача состоит в том, чтобы эффективно инкапсулировать лайку и данные, связанные с процессами в реальном мире. Значительные интеллектуальные усилия требуются для принятая решений, что можно объединить, а что должно быть реализовано отдельными сервисами.
• Сообщения. Сервисы взаимодействуют между собой, обмениваясь сообщениями. Должны быть полностью определены сообщения, которые порождают и принимают сервисы, включая требования к последователь- ности этих сообщений.
• Контракты. Каждый контракт описывает метод взаимодействия двух сервисов. В это описание входит: перечень посылаемых каждым сер- висом сообщений, их форматы, методы отправит, последовательность об- мена сообщениями, перечень принимаемых каждым сервисом сообщений и способы приёма.
• Политики. Политики должны давать возможность влиять на работу приложений, т.е. устанавливать и изменять правила, действующие во вре- мя выполнения, которые определяют методы работы сервисов и их взаи- модействие. Разработка политик в ходе процесса проектирования ведёт к увеличению гибкости и управляемости приложений.
• Состояния. Сервисы управляют состояниями и состояния, часто, являются главной причиной их существования. Состояние - это то, что хранится в некоторой долгосрочной среде, такой как файловая система или база данных. Сервисы гарантируют посредством своей бизнес-логики, содержательность, непротиворечивость и точность сохраняемых состоя- ний. В процессе работы сервисы будут получать запросы от других серви- сов, извлекать некоторые состояния из этой среды длительного хранения и строить ответы или корректировать эти состояния.
166
• Процессы. Каждый процесс управляет последовательностью дейст- вий при выполнении некоторой работы, постепенно переводя систему из одного состояния в другое. В сервисо-ориентированной архитектуре должны быть спроектированы бизнес-сервисы, построенные по традици- онным принципам, и процессные сервисы, которые будут координировать выполнение бизнес-сервисов.
• Приложения. Приложения объединяют процессные сервисы, биз- нес-сервисы и сервисы пользовательских интерфейсов. Бизнес-сервисы
• Приложения. Приложения объединяют процессные сервисы, биз- нес-сервисы и сервисы пользовательских интерфейсов. Бизнес-сервисы обычно проектируются в четыре слоя: сервисы фасада, сервисы бизнес- процессов, сервисы бизнес-сущностей и сервисы представления данных.
Такая уод&пь работоспособна как для традиционных типов приложений, которые имеют интерфейс для взаимодействия пользователей с бизнес- сервисами, так и для сервисов, взаимодействующих с другими сервисами.
Помимо концептуального представления при проектировании серви- со-ориентированной архитектуры должны быть спроектированы логиче- ское представление и физическое представление. Мы не будем на них подробно останавливаться поскольку они в существенно меньшей степени отличаются от соответствующих представлений яри проектировании тра- диционной архитектуры.
Преобразование унаследованных приложений к сервисо- ориентированной архитектуре (SOA)
167
1 ... 7 8 9 10 11 12 13 14 15
Тема 7. Организация технического обслуживания и эксплуата-
ции информационных систем.
1. Значение технического обслуживания
2. Что такое гарантия
3. Программы технического обслуживания
4. Схемы технического обслуживания
1. Значение технического обслуживания
Сейчас все реже высказывается мнение о том, что можно обойтись без технического обслуживания и без IT-услуг со стороны специализиро- ванных внешних компаний. Практика показывает, что оставаться один на один со своей информационной системой не только рискованно, но зачас- тую просто губительно для бизнеса всей компании в целом. Однако для окончательного решения вопроса — что такое хорошо и что такое плохо
— нам часто не хватает конкретных цифр или методик оценки стоимости простоя.
Поэтому, прежде чем обратиться к рассмотрению вопросов, связан- ных с возможностями, предоставляемыми в рамках гарантийного или тех- нического обслуживания информационных систем на этапе ее эксплуата- ции, попытаемся понять, насколько дорогостоящим может оказаться про- стой информационной системы и исполняемых ею задач, неоптимальное использование ее возможностей. Это позволит уяснить практическую роль технического обслуживания для решения задач, периодически возникаю- щих при эксплуатации информационных систем.
Очевидно, что наибольшие прямые или косвенные потери компании, в первую очередь, связывают с нарушением нормального ритма работы компании, а тем более с полной остановкой бизнес-процессов. Это озна- чает, что практически любой аварийный останов любого сервера или при- ложения, так или иначе скажется на эффективности работы компании в целом.
Реальные цифры потерь, обусловленные простоем информационной системы, с одной стороны, просчитать достаточно сложно, а, с другой стороны, никто не хочет "выносить сор из избы". Поэтому попробуем на примере некоторой усредненной компании "поиграть" цифрами и при- мерно оценить, насколько серьезными могут быть прямые и косвенные финансовые потери от вынужденных простоев информационной системы на этапе ее реальной эксплуатации.
Размеры убытков, связанных с простоем информационной системы, зависят в немалой степени от специфики компании и решаемых ею задач.
При выполнении подобных расчетов полезно обратить внимание, напри- мер, на информацию, которая публикуется специализированными иссле-
168 довательскими компаниями. Так, согласно статистическим исследованиям американской компании Infanetics, среднее время простоя информацион- ной системы среднего размера составляет примерно 6% времени ее рабо- ты. Статистика по 100 ведущим американским компаниям показывает, что среднее количество остановок систем составляет около 24 в год при сред- ней продолжительности остановки около 5 часов.
Среднестатистическое число отказов средней информационной сис- темы можно определить и по среднему времени наработки на отказ. Рас- смотрим, например, блок питания, который является достаточно уязви- мым элементом оборудования. Если среднее время наработки на отказ для блока питания составляет 50 000 часов и информационная система экс- плуатируется круглосуточно, то получаем см. таблицу 1.
Результаты обнадеживают, если не вспоминать, что в информацион- ной системе эксплуатируется далеко не один блок питания. Достаточно умножить количество блоков питания на только что полученный резуль- тат (а для информационной системы средних размеров количество ис- пользуемых блоков питания измеряется сотнями), то очень хорошим по- казателем будет, если в течение месяца откажет только один блок пита- ния. В реальности количество отказов может оказаться существенно большим.
Таблица 1.
Среднее время наработки на отказ, часов
50000
Дней в году
365
Часов в сутках
24
═
1 отказ в 5,7 года
Подсчитаем оборот эксплуатирующей информационную систему ор- ганизации на отдельно взятого сотрудника (разделим объем продаж на ко- личество работающих в организации сотрудников) и затем разделим ре- зультат на количество рабочих часов в году. Результатом является оборот компании в расчете на одного сотрудника за один час. Умножим это число на количество часов, в течение которых простаивает информационная система (число отказов, умноженное на число часов простоя). Результатом вычислений являются потери в обороте организации за год, приходящиеся на одного сотрудника (таблица 2).
Таблица 2.
Оборот организации за год
$10.000.000
Количество сотрудников
150
Оборот на сотрудника за год
$66.666
Количество рабочих часов
2.080
169
Оборот на сотрудника в час
$32
Оборот на всех сотрудников в час
$4800
Количество часов простоя систем
120
Потери в обороте организации за год из-за простоев информационной системы
$576.000
Как видно из расчетов, потери от простоев информационной систе- мы только за один год — вполне могут быть сравнимы со стоимостью са- мой информационной системы.
Далее умножим количество сотрудников в организации, чья работа прямо или косвенно связана с использованием информационной системы, на среднечасовую оплату труда, а затем на количество часов простоя сис- темы. Результатом будет максимум потерь производительности труда в год (таблица 3).
Таблица 3.
Среднечасовая оплата труда
$3
Количество сотрудников
150
Оплата в час для всех сотрудников
$450
Количество часов простоя в сети
120
Потеря производительности в год
$54.000
Если методика расчета прямых потерь достаточно проста и не требу- ет объяснений, то с расчетом косвенных потерь дело обстоит не столь очевидно. Как, например, оценить потери имиджа компании от простоев информационной системы? Пожалуй, это труднее всего поддающаяся расчету характеристика.
Однако некоторые методики расчета, все-таки существуют. В одной из статей LAN Times использовалась формула умножения коэффициента
0,001 на объем годового оборота и на количество дней простоя информа- ционной системы. Эта формула не учитывает таких необычных факторов, как риск для жизни, когда речь идет, например, об информационной сис- теме, установленной в больнице, однако, в целом позволяет ориентиро- вочно определить сумму косвенных потерь от вынужденных простоев
(таблица 4).
Таблица 4.
Объем продаж в год * коэффициент
$10.000.000 * 0.001 = $10.000
Дней простоя
15
Стоимость потерь имиджа компании от
простоев информационной системы за год
$150.000
Сразу оговоримся, что не существует общепринятых методов каль- куляции стоимости простоев информационной системы. Однако уже из