В эволюции взаимодействия ИТ-разработки и бизнеса период простой автоматизации процессов уступил место интеграции информационных продуктов в бизнес-модели. Теперь ИТ-разработка не только поддерживает бизнес, но и является непосредственным соучастником его развития, предоставляя новые возможности для создания ценности.
Разумеется, автоматизация бизнес-процессов всё ещё является преимущественным использованием информационных систем, однако тренд в сторону включения ИТ-разработки в развитие бизнес-моделей непрерывно нарастает. И уже наметилось смещение в сторону следующего шага, когда бурный рост информационных технологий становится основой для экспериментов и поиска новых источников для бизнеса. Создание экосистем управления потребителями, омниканальность, персонализация, цифровая логистика, монетизация данных и многое другое — это энейблеры уже сегодняшнего дня.
И в чем подвох?
Как просто описывать бизнес-процессы и их оцифровка в Битрикс24.
Когда ИТ-разработка становится уже не поддержкой, но полноценным соучастником развития бизнеса, жизненно важным является соответствие скорости реагирования на изменяющиеся запросы бизнеса. Интенсивность создания ценности в ИТ-продуктах должна соответствовать темпам развития бизнес-моделей.
Разумеется, в зависимости от особенностей бизнеса эти темпы будут очень разные. Где-то и проектный подход сохранит свои несомненные преимущества в организации управления ИТ-разработкой. Однако он плохо работает на высоких скоростях в тех секторах бизнеса, где быстрый отклик на изменение рынка является залогом успеха, а также там, где непрерывное совершенствование качества продукта составляет бизнес-ценность.
В таких компаниях последовательно идёт трансформация организационного управления в сторону гибких методологий. В принципы организации труда заносятся Agile, DevOps, продуктовый подход.
Все эти методологии декларируют клиентоориентированность, необходимость устранения барьеров между бизнес-заказчиками и ИТ-разработчиками. Однако зачастую непосредственным соучастникам трансформации совершенно непонятно, для чего им эти коммуникации? Какая зримая польза от их усилий, и куда эти усилия необходимо прилагать?
Сделай то, не знаю что!
Чаще всего в компаниях цифровая трансформация является стратегической инициативой, спускаемой сверху. Обозначаются некие целевые состояния, изменения, охватывающие крупномасштабные бизнес-структуры. На непосредственных провайдеров этих изменений, заинтересованных лиц, поддерживающих устойчивость бизнес-моделей и эффективность бизнес-процессов, приземляются некие установки без конкретного разъяснения, как это должно работать.
Иными словами, на уровень линейных менеджеров прилетает распоряжение выстроить взаимодействие с ИТ-разработкой, исходя из новых стратегий развития. И явно обозначается, что в случае неудачи спросят тоже с них.
Уполномоченные таким образом представители бизнеса оказываются в ситуации, когда стратегия изменений им понятна, а вот тактика реализации в руки не даётся. Предполагается, что специалисты высокого уровня, каковыми являются владельцы бизнес-функций, в состоянии сами принимать решения и отлаживать коммуникации с ИТ-разработкой в новых целевых состояниях.
Business Studio 4.0: проектирование системы целей, бизнес-процессов, организационной структуры
И это действительно так. Только вот типичный линейный менеджмент хорошо умеет управлять, используя привычные инструменты, на директивах и дедлайнах. Более того, сам бизнес зачастую имеет жёсткую бюрократическую иерархическую структуру и не собирается меняться. Оставляя все отстройки новых организационных структур в сторону гибких методологий управления исключительно на стороне ИТ-разработки.
Замечено, что разработчики легче и с большим энтузиазмом воспринимают цифровую трансформацию. Им она более понятна, чем бизнес-заказчикам, с которыми они взаимодействуют. Не в малой степени это происходит потому, что айтишники постоянно находятся в состоянии получения новых знаний. У них происходящие изменения являются естественным продолжением эволюции управления, которая в их мире всегда была интенсивной.
А вот бизнесу, живущему в системе иерархии рангов уже лет триста, очень сложно осознать необходимость стать командным игроком и понять свою роль в управлении ИТ-продуктом. Цепочка создания ценности рассыпается на отдельные звенья.
Это не мои проблемы!
Чем это чревато? Изменения, производимые на стороне бизнеса, не синхронизированы с действиями ИТ.
Когда речь заходит о необходимости продуктового подхода, бизнес подразумевает под этим свой собственный бизнес-продукт. А ИТ-разработчики – информационную систему, над приращением функциональных возможностей которой работают.
Это расхождение в самых базовых понятиях может быть совершенно не очевидно самим соучастникам процесса.
Ответственные за бизнес-область менеджеры сосредоточены на развитии бизнес-продукта. Это огромная работа в физической среде: управление закупками оборудования и расходных, обучение и развитие персонала, согласование юридических аспектов, бюджетирование, регламентация, лицензирование… Очень много процессов может изменяться в соответствии со стратегическими задачами компании в развитии бизнеса! А следовательно, требовать управления от конкретных владельцев бизнес-функций.
В этом аспекте бизнес склонен делегировать внутреннее развитие ИТ-систем в руки профессионалов от разработки и ожидать готового результата по своему запросу. То есть он совершенно не рассматривает в качестве продукта информационную систему и не включает в контур своей деятельности необходимость управления ИТ-продуктом. Зачем?
Даже приняв на себя роль владельца ИТ-продукта, представитель бизнеса продолжает вести себя как сторонний заказчик. Искренне недоумевая, почему он должен тратить свой ресурс на управление непрозрачными и непонятными ему процессами.
Кто крайний?
Бизнес хочет получить результат по своему запросу на изменение той или иной функциональности от команды ИТ-разработки. И результат он получает. И очень удивляется! Потому что результат сильно далёк от его ожиданий.
Представьте, что в вышеописанной ситуации включения ИТ-разработки в бизнес-модели раз за разом результат не будет соответствовать ожиданиям. При интенсивном потоке запросов и сильной зависимости процессов в физической среде бизнес-области с возможностями интегрированных ИТ-систем.
Тогда имеем следующую ситуацию: управляя бизнес-продуктом, его владелец проделывает большое количество дорогостоящих подготовительных изменений, но результат от ИТ-разработки для него остаётся непредсказуем. Уже пора обучать персонал, менять скрипты, заключать договоры? Стоит ли проделывать сложную работу, если в итоге в решающий момент она окажется невостребованной, потому что разработка выдала не то, что ожидалось?
Если отбросить в сторону эмоциональный контекст и поиски виноватых, в сухом остатке будет острая необходимость сфокусировать команду ИТ-разработки на поставку бизнес-ценности, а не только лишь результата. То есть ИТ-продукт должен развиваться строго в направлении, выбранном бизнесом.
Делай, что нужно, а что не нужно – не делай!
Так делается первый шаг на пути управления ИТ-продуктом. Понимание ценности задач, запросов на изменение находится в руках бизнеса.
Донесение ценности, постоянная фокусировка на ожиданиях бизнеса требует отстройки непрерывного обмена информацией, циклов обратной связи, устойчивых коммуникаций.
А кроме того, ИТ-разработчикам вовсе не хочется делать лишнюю работу, которая на выходе будет отвергнута и выброшена в мусор. Это демотивирует, лишает смысла и продуктивности. В сложной интеллектуальной деятельности, которой является создание программных продуктов, отсутствие значимых, зримых, воплотившихся в материальные изменения результатов работы очень быстро подавляет продуктивность.
Представьте себе ситуацию, когда вы пишете сочинение на чётко сформулированную тему, а вам за него ставят самую низкую оценку с формулировкой «тема не раскрыта». И так раз за разом. Очень скоро вы будете писать такие сочинения без всякого энтузиазма, потому что создаётся устойчивое впечатление, что любим решением будут недовольны. Или «сами не знают, чего хотят». А тогда зачем прилагать усилия?
Поэтому фокусировка на ценности, на том, что действительно двигает развитие бизнеса, очень важна. В нематериальной интеллектуальной деятельности нет другого способа получить желаемый результат и замотивировать людей. Тут не помогают скрипты, ГОСТЫ и шаблоны, потому что слишком велика неопределённость в пространстве поиска решений.
Поэтому довольно быстро бизнес осознает, что в новой ситуации надо делать шаг в сторону управления ИТ-продуктом и фокусировать команду на бизнес-ценности. В том числе, чтобы не оказаться крайним в ситуации, когда деятельность ИТ-разработки выдаёт некачественный результат и тем самым тормозит развитие.
Какие инструменты есть для этого в руках бизнеса – тема отдельной статьи. Если вы зафиксируете в комментариях ваш интерес на эту тему, я обязательно поделюсь своими наработками.
Итак, первый шаг в выстраивании коммуникаций между заинтересованным владельцем бизнес-функций и командой, развивающей ИТ-продукт, сделан. Уже прекрасно! Что часто происходит дальше?
Сделаю за час в течение недели до конца месяца
Предположим, что команда разработчиков научилась фокусироваться на ценности, и результаты их работы соответствуют ожиданиям бизнеса. Но поставка ценности в бизнес-среду идёт с непредсказуемой частотой, как правило, слишком медленно.
Со стороны бизнеса это означает, что линейные менеджеры не знают когда и в каких точках прилагать усилия по развитию собственного бизнес-продукта. Когда инициировать всю ту механику перестройки бизнес-процессов, о которой уже говорилось выше? Как прогнозировать развитие и удерживать управление всей бизнес-области как единым целым?
Именно потому, что бизнес несёт ответственность за очень большое количество сложных процессов, он обожает управление на дедлайнах. Так можно разложить в связную схему последовательность действий, алгоритм запуска бизнес-процессов, поэтапные изменения.
Однако, к сожалению, возможность регулировать поставки ценности от ИТ-разработки на дедлайнах – это опасная иллюзия. Причём бизнес-владельцы продукта прекрасно об этом знают. Их распространённый приём: если на ожидаемый срок накинуть 30% времени, то попадём точно в срок. На этом, зачастую, и строится прогнозирование сложных и дорогостоящих изменений.
Когда темп развития бизнеса ускоряется, этот подход больше не работает.
Бизнес делает следующий шаг, приносит дорожную карту развития бизнес-продукта и пытается синхронизировать её с дорожной картой развития ИТ-продукта. Чтобы задать нужный темп разработчиками. И бездны великие распахиваются у него под ногами, потому что оказывается, что размерность элементов работы у этих продуктов фатально не совпадает. То, что бизнес считает задачами и измеряет штуками, для ИТ-разработчика является функциональным сценарием и рассыпается на десятки задач.
Вопрос синхронизации темпов создания ценности в единой цепочке – это снова тема для отдельной статьи. Это сложный процесс, который начинается с выстраивания общей системы понятий и терминов. Что уж говорить, даже к такому важному и полезному инструменту как дорожная карта продукта подходят далеко не сразу. А изначально диалог ведётся на пальцах, как и положено глухонемым.
Хочешь сделать что-то хорошо, сделай это сам!
Итак, уже два шага навстречу друг другу в процессе выстраивания коммуникаций. Уже начинает просыпаться сознание, что существенная часть управления развитием ИТ-продуктов находится в руках бизнеса, может им контролироваться.
Дальше закономерно возникают новые вопросы: а какое количество бизнес-задач в принципе способна решать команда ИТ-продукта? Какова её пропускная способность? Каков недостаток в ресурсах? На каких данных можно делать обоснованный прогноз о поставке ценности?
Какие метрики позволят оценить возможности для бизнеса на различных этапах, от планирования развития бизнес-продукта, до оценки прогресса по текущим запросам. И так далее, и так далее.
Все это в какой-то момент приводит к тому, что создаётся единый интерфейс управления ИТ-продуктом. В этом интерфейсе бизнес и ИТ-разработчики действуют в поле единого понимания целей развития и производимой бизнес-ценности, пользуются общей терминологией, учатся применять и развивают инструменты управления рабочими процессами, основывают свои выводы на едином пространстве данных, создают систему правил для организации комфортной среды коммуникаций и оперативного обмена информацией.
Отстройка такого интерфейса – необходимый элемент, позволяющий переключиться с ручного микроменеджмента отдельно взятых запросов на управление потоком изменений в требуемом темпе. И, разумеется, этот интерфейс индивидуален, но подходы к его выстраиванию в целом сходные. Двигаясь пошагово навстречу друг к другу, бизнес и ИТ-разработка проявляют «серые зоны» и вырабатывают организационные изменения, необходимые для совместного управления продуктом.
Ещё о сложности мира
Что важно отметить. В исторически сложившемся ИТ-ландшафте крупных компаний крайне редко бывают ситуации, когда развитие бизнес-продукта зависит от одной конкретной информационной системы. Как правило, развитие бизнеса базируется на целом спектре ИТ-продуктов со своей спецификой управления.
Это означает, что у одного ИТ-продукта роль Владельца продукта (PO) в бизнесе делегирована нескольким стейкхолдерам. Каждый из которых является для продуктовой команды равноценно важным источником запросов. Для ИТ-разработчиков это очень травмирующая ситуация, которая усложняет применение практик гибких методологий управления в их рабочих процессах.
С другой стороны, каждый бизнес-продукт точно так же в своём развитии зависит не от одного ИТ-продукта, а от определённой функциональной области со сложной и сильно связанной экосистемой информационных систем. А это означает, что бизнес-владелец должен управлять не одним ИТ-продуктом, а целой пачкой систем, соучаствующих в создании ценности. Что конечно же требует больших ресурсозатрат.
Все это надо учитывать при выстраивании интерфейса управления ИТ-продуктами. Отказ от такого управления исключает возможность выстраивания единой цепочки создания ценности и интеграции цифровых технологий в бизнес-модель. Разделение процессов в бизнесе и ИТ-разработке должно последовательно и осознанно устраняться.
Надеюсь, эта статья помогла вам ответить на вопрос: зачем бизнесу управлять ИТ-продуктами? Не сомневаюсь, что она породила множество других вопросов: кто? как? с помощью чего? Но это уже совсем другая история.
Также по теме:
- Зачем бизнесу SLA?
- Зачем нужен Change Management?
- «12 шагов к гибкому бизнесу» — новая книга Cleverics
- Нужен ли ITIL малому и среднему бизнесу?
- Зачем нужен ITSM?
Источник: cleverics.ru
Интерфейс бизнес-процессов с помощью требования
Требование Интерфейс Требование
| Поставщик |
| ->■ Клиент |
Бизнес-процесс
| (Продукт/ услуга) |
(Исходный материал)
 |
Рис. 1. Интерфейс бизнес-процесса с помощью требования
В схеме взаимодействия бизнес-процессов «клиент-исполнитель» цепочка создания добавленной стоимости организуется не на основе директивных заданий, а на основе договорных отношений, в которых оговариваются условия поставок (вид продукции/услуг, внутренние цены, особые условия).
Интерфейс бизнес-процессов с помощью плана-графика
На однородных предприятиях схема множества двухсторонних договорных отношений «клиент и исполнитель» может быть заменена на схему «1 владелец процесса — N владельцев ресурсов». Клиент процесса в этом случае становится единоличным владельцем некоторого макропроцесса, координирующим выполнение отдельных бизнес-процессов, а владельцы отдельных процессов превращаются, по сути, во владельцев ресурсов или, точнее, в поставщиков необходимых ресурсов.
Владелец процесса (ИНТЕРФЕЙС — план-график)
 1 |
F |
 Функция 1 |
Функция 2 |
 |
 |
Ресурс 1 Ресурс 2 Ресурс N
Рис. 2. Интерфейс бизнес-процесса с помощью плана-график
Использование планов-графиков, устанавливающих четкие временные рамки и ответственность владельцев ресурсов, устраняет процесс согласования работ между взаимодействующими бизнес-процессами, но добавляет вспомогательный процесс создания и корректировки единых регламентирующих плановых документов.
В обоих случаях организации интерфейсов между бизнес-процессами происходит существенное изменение организационной структуры предприятия.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Тема8-Интеграция_ИС. Интеграция приложений и информационных систем Информационные системы предприятия и их подсистемы
Единственный в мире Музей Смайликов
Самая яркая достопримечательность Крыма
Скачать 229.5 Kb.
Интеграция приложений и информационных систем
1. Информационные системы предприятия и их подсистемы.
1) системы с эксплуатационным уровнем системы диалоговой обработки запросов – Transaction Processing Systems ( TPS )
2) системы уровня знания системы работы знания – Knowledge Work System ( KWS )
системы автоматизации делопроизводства – Office Automation Systems (OAS)
3) системы уровня управления управляющие информационные системы – Management Information Systems (MIS )
системы поддержки принятия решений – Decision Support Systems ( DSS )
4) системы со стратегическим уровнем системы поддержки выполнения – Executive Support Systems ( ESS )
Взаимосвязь модулей ИС
Модуль TPS обслуживает основные производственные и вспомогательные процессы, и обычно это главный источник для других информационных модулей.
ESS — главный получатель данных и внутренних систем из внешней среды.
Связи между DSS и совокупностью TPS, KWS , MIS намеренно показаны неопределенными. Иногда DSS тесно связана с другими подсистемами. Но это только в том случае, если предприятие отличается высокой степенью автоматизации всех процессов. Обычно подсистема DSS изолирована от основных производственных информационных систем и использует их данные и информационные потоки для работы своих аналитических систем.
2. Понятие интеграции.
Интеграция ИС – объединение ИС, связывающее множество документов и отношений в данных системах .
Под ИС понимается множество связанных различными отношениями документов, описывающих некоторые сущности (объекты, факты или понятия).
Стандарт EAI
EAI (Enterprise application integration) – интеграционная программная структура, объединяющий различного рода приложения, разработанные независимо друг от друга, так, чтобы они работали как одно целое, прозрачно для пользователя
Подходы к интеграции.
В наши дни чаще всего применяются два подхода: интеграция по типу «точка-точка» (point-to-point integration) и интеграция по шине сервисов (services bus integration).
3. Проблемы совместимости программных продуктов, ИС.
Информация не найдена
4. Уровни интеграции
Можно выделить 5 уровней интеграции:
Интеграция бизнес-процессов – основана на определении, реализации и управлении процессами обмена информацией между различными бизнес-системами.
Интеграция приложений – основана на объединении данных или функций одного приложения с другим, благодаря чему обеспечивается интеграция, близкая к реальному времени.
Интеграция данных – основана на идентификации и каталогизации данных с целью их дальнейшего использования.
Интеграция на основе стандартов – основана на использовании стандартных форматов данных (например, CORBA, JavaRMI, XML).
Интеграция платформ – касается процессов и инструментов, с помощью которых системы могут осуществлять безопасный и оптимальный обмен информацией.
5. Характеристика уровня интеграции бизнес-процессов.
Интеграция бизнес-процессов представляет собой автоматизацию бизнес-процессов организации на основе единой инфраструктуры по созданию и управлению бизнес-процессами. Такая интеграция позволяет объединить в единый бизнес процесс действия, выполняемые в разных прикладных системах. Такая интеграция позволяет:
моделировать бизнес-процессы;
обеспечить соблюдение правил выполнения бизнес процессов;
предоставить пользователем единый интерфейс для выполнения задач в рамках бизнес процессов;
обеспечить контроль над выполнением и аудит бизнес процессов;
вносить изменение в бизнес процессы в соответствии с требованиями бизнеса;
получить данные для анализа выполнения и оптимизации бизнес процессов.
6. Характеристика уровня интеграции приложений.
Интеграция приложений по данным представляет собой организацию взаимодействия приложений посредством передачи данных, между этими приложениями, без модификации или с минимальной модификацией самих приложений.
При этом данные могут передаваться как в исходном виде, так и с выполнением необходимых преобразований.
7. Характеристика уровня интеграции данных.
Гарантия качественной интеграции приложений и бизнес-процессов — это интеграция данных и систем баз данных.
На этом уровне в целях интеграции данные должны быть:
идентифицированы (то есть указано их местоположение в распределенной системе);
каталогизированы;
должна быть построена модель метаданных (т.е. описание данных о данных).
После завершения трех этих этапов данные можно совместно распространять или использовать в системах баз данных.
8. Характеристика стандартов интеграции.
Среди этих стандартов известны спецификации:
COM / DCOM (Component Object Model / Distributed Component Object Model) фирмы Microsoft;
Enterprise Java Beans – EJB (основной конкурент DCOM) с протоколом Java Remote Method Invocation (Java RMI) фирмы Sun Microsystems;
спецификации компонентов в архитектуре CORBA, поддерживаемые консорциумом OMG;
стандарты компонентной разработки Web-приложений, предложенные консорциумом World Wide Web Consortium (W3C) — XML (англ. eXtensible Markup Language — расширяемый язык разметки)
Как правило, средствами интеграции приложений в данной группе средств выступают службы программного обеспечения промежуточного слоя (middleware).
Такие службы иногда называют связующим программным обеспечением.
Они обеспечивают прозрачную работу приложений в неоднородной сетевой среде, предоставляя им услуги в виде интерфейсов прикладного программирования (API), чтобы обеспечить взаимодействие частей приложений, распределенных по разным узлам корпоративной сети.
К службам middleware, прежде всего, относятся службы вызова удаленных процедур RPC (Remote Procedure Call), обмена сообщениями и посредники (брокеры) запросов к объектам ORB (Object Request Brokers), мониторы транзакций.
Благодаря использованию указанных выше стандартов при компонентной разработке приложений, становится возможным широко реализовать на практике преимущества повторного использования компонентов – повышение производительности труда при разработке, простоту применения, единообразие структуры приложений.
9. Характеристика уровня интеграции платформ.
Чтобы завершить интеграцию систем — базовой архитектуры, аппаратного и программного обеспечения — необходимо интегрировать разнесенные части гетерогенной сети (т.е. имеются разные машинные архитектуры и операционные системы).
Интеграция платформ касается процессов и инструментов, с помощью которых эти системы могут осуществлять безопасный и оптимальный обмен информацией. В результате, данные могут беспрепятственно передаваться по различным приложениям.
10. Качество программного интерфейса.
Индекса качества программного интерфейса можно измерять в диапазоне от нуля до единицы, от полного отсутствия какого бы то ни было программного интерфейса до наличия исчерпывающе полного (в смысле доступности прикладной функциональности) программного интерфейса.
11. Открытость программного интерфейса.
индекс открытости программного интерфейса — измеряется в пределах от нуля до единицы, от полностью закрытого (ничего не опубликовано), до полностью открытого интерфейса (опубликован интерфейс ко всем прикладным функциям приложения).
12. Интегрируемость программного интерфейса.
Индекс интегрируемости приложения можно определить как индекс качества программного интерфейса, помноженный на индекс открытости программного интерфейса. В результате мы получим числовой показатель, который (в известной степени) характеризует способность приложения быть частью какого-то другого, глобального приложения (сейчас популярен термин композитное приложение).
13. Принцип открытости ИС
Открытая система — исчерпывающий и согласованный набор международных стандартов на информационные технологии и профили функциональных стандартов, которые специфицируют интерфейсы, службы и поддерживающие их форматы, чтобы обеспечить взаимодействие и мобильность программных приложений, данных и персонала
Общие свойства открытых информационных систем:
расширяемость/масштабируемость;
мобильность/переносимость;
взаимодействие;
стандартизуемость;
дружественность к пользователю
14. Понятие композитного приложения
Композитное (составное) приложение — программное решение для конкретной прикладной проблемы, которое связывает прикладную логику процесса с источниками данных и информационных услуг, хранящихся на гетерогенном множестве базовых информационных систем.
Обычно композитные приложения ассоциированы с процессами деятельности и могут объединять различные этапы процессов, представляя их пользователю через единый интерфейс.
15. Архитектура ИС.
Архитектура информационной системы — концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.
Файл-серверная архитектура
Клиент-серверная архитектура
Тонкий клиент
Толстый клиент
Трехслойная архитектура
Файл-серверная архитектура
Как исполняемые модули, так и данные размещаются в отдельных файлах операционной системы.
Для хранения данных используется выделенный сервер (отдельный компьютер), который и является файловым сервером. Исполняемые модули хранятся либо на рабочих станциях, либо на файловом сервере.
Клиент-серверная архитектура
Клиент (исполняемый модуль) запрашивает те или иные сервисы в соответствии с определенным протоколом обмена данными. При этом, в отличие от ситуации с файловым сервером, нет необходимости в использовании прямых путей операционной системы.
Трехслойная архитектура
Базируется на дальнейшей специализации компонент архитектуры: клиент занимается только организацией интерфейса с пользователем, сервер баз данных — только стандартизованной обработкой данных. Для реализации логики обработки данных архитектура предусматривает отдельный слой — слой бизнес-логики.
16. Классификация ИС по архитектуре.
По степени распределённости отличают:
Локальные ИС, в которых все компоненты (БД, СУБД, клиентские приложения) работают на одном компьютере;
Распределённые (distributed) ИС, в которых компоненты распределены по нескольким компьютерам.
Распределённые ИС, в свою очередь, разделяют на
файл-серверные ИС (ИС с архитектурой «файл-сервер»). База данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях.
клиент-серверные ИС (ИС с архитектурой «клиент-сервер»). База данных и СУБД находятся на сервере, а на рабочих станциях находятся клиентские приложения.
В свою очередь, клиент-серверные ИС разделяют на двухзвенные и многозвенные.
В двухзвенных (two-tier) ИС всего два типа «звеньев»: сервер баз данных, на котором находятся БД и СУБД, и рабочие станции, на которых находятся клиентские приложения. Клиентские приложения обращаются к СУБД напрямую.
В многозвенных (multi-tier) ИС добавляются промежуточные «звенья»: серверы приложений (application servers). Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями.
17. Архитектура SOA.
SOA (англ. Service Oriented Architecture) — это прикладная архитектура, в которой все функции определены как независимые сервисы с вызываемыми интерфейсами. Обращение к этим сервисам в определенной последовательности позволяет реализовать тот или иной бизнес-процесс
Идея SOA заключается в создании архитектурной платформы, которая обеспечит быструю консолидацию распределенных компонентов — сервисов — в единое решение для поддержки определенных бизнес-процессов.
Принципы SOA:
Архитектура, как таковая, не привязана к какой-то определённой технологии,
Независимость организации системы от используемой вычислительной платформы (платформ),
Независимость организации системы от применяемых языков программирования,
Использование сервисов, независимых от конкретных приложений, с единообразными интерфейсами доступа к ним,
Организация сервисов как слабосвязанных компонентов для построения систем
18. Понятие «тонкого» и «толстого» клиента, примеры.
В рамках направления «клиент-сервер» существуют два основных «диалекта»:
«тонкий» клиент;
«толстый» клиент.
В системах на основе тонкого клиента используется мощный сервер баз данных — высокопроизводительный компьютер и библиотека так называемых хранимых процедур, позволяющих производить вычисления, реализующие основную логику обработки данных, непосредственно на сервере.
Клиентское приложение, соответственно, предъявляет невысокие требования к аппаратному обеспечению рабочей станции.
Толстый или Rich-клиент в архитектуре клиент-сервер — это компьютер, обеспечивающий расширенную функциональность независимо от центрального сервера.
Как правило, сервер в этом случае является лишь хранилищем данных, а вся работа по обработке и представлению этих данных переносится на машину клиента.
Достоинства
Толстый клиент обладает широким функционалом в отличие от тонкого.
Режим многопользовательской работы.
Предоставляет возможность работы даже при обрывах связи с сервером.
Имеет возможность подключения к банкам без использования сети Интернет.
высокое быстродействие.
Недостатки
Большой размер дистрибутива.
Многое в работе клиента зависит от того, для какой платформы он разрабатывался.
При работе с ним возникают проблемы с удаленным доступом к данным.
Довольно сложный процесс установки и настройки.
Сложность обновления и связанная с ней неактуальность данных.
В настоящее время известны следующие реализации толстого клиента:
ArchiMed — медицинская информационная система
R-Keeper Delivery — автоматизация доставки готовой продукции
R-Keeper POS-ITV — система видеоконтроля
R-Keeper Self-Service — система самообслуживания
R-Keeper — автоматизация ресторанного бизнеса
SET Prisma – система контроля кассовых оперций
Shelter – автоматизация гостиниц
StoreHouse — учётная система ресторанного бизнеса
Time-Keeper — система учета рабочего времени
Абонемент — автоматизация фитнес и спа-центров
АТОЛ — рабочее место кассира
Кассовый программный модуль Кристалл-УКМ
Кассовый программный модуль Супермаг-УКМ
Примеры тонких клиентов
Thinstation — дистрибутив GNU/Linux, разработанный специально для cоздания тонких клиентов.
LTSP (англ. Linux Terminal Server Project) — пакет дополнений для GNU/Linux, позволяющий подключить большое количество низкопроизводительных тонких клиентов к серверу.
OpenThinClient
Windows CE
Бездисковая станция
Терминальный доступ
Virtual Network Computing
19. Понятие информационной услуги (сервиса).
Информационная услуга — услуга, ориентированные на удовлетворение информационных потребностей пользователей путем предоставления информационных продуктов.
ИТ-сервис в корпоративной среде – это ИТ-услуга, которую ИТ-подразделение (департамент, отдел, служба) или внешний провайдер предоставляет бизнес-подразделениям предприятия для поддержки их бизнес-процессов.
В общем случае ИТ-сервис характеризуется рядом параметров :
функциональность;
время обслуживания;
доступность;
надежность;
производительность;
конфиденциальность;
масштаб;
затраты.
Понятие web-сайтов и порталов, корпоративные порталы.
Веб-сайт (от англ. website: web — «паутина», «сеть» и site — «место», букв. «место в сети») или просто сайт — в компьютерной сети объединённая под одним адресом (доменным именем или IP-адресом) совокупность документов частного лица или организации. По умолчанию подразумевается, что сайт располагается в сети Интернет.
Портал — это информационный сетевой ресурс, позволяющий получать сконцентрированную информацию по определенной теме и изменять её путем взаимодействия человека и компьютера.
Корпоративный информационный портал (КИП) предназначен для создания единого информационного пространства компании и позволяет интегрировать в единое целое разнородные корпоративные приложения, предоставляя им единый интерфейс доступа.
Функциональность портала определяется потребностями заказчика. Обычно в рамках КИП осуществляются следующие процессы и оказываются следующие сервисы:
обеспечение информационной поддержки сотрудников и клиентов компании;
организация коллективной работы и взаимодействия удаленных рабочих групп;
управление правами доступа, персонализация предоставляемых данных;
управление публикациями (размещением и редактированием информации);
организация доступа к приложениям и данным через web-браузер с любого компьютера, подключенного к Интернету.
21. Идентификация пользователей – авторизация, аутентификация.
Аутентифика́ция (англ. Authentication) — проверка принадлежности субъекту доступа предъявленного им идентификатора; подтверждение подлинности.
Авторизация (англ. authorization):
1. Процесс предоставления определенному лицу прав на выполнение некоторых действий.
2. Процесс подтверждения (проверки) прав пользователей на выполнение некоторых действий.
В информационных технологиях посредством авторизации устанавливаются и реализуются права доступа к ресурсам и системам обработки данных.
Авторизация как правило — следующий шаг системы после аутентификации.
Источник: topuch.com
