Что такое компонентный бизнес

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

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

Это позволяет программистам создавать продукты, хотя бы частично состоящие из повторно использованных частей, т. е. использовать технологию, хорошо зарекомендовавшую себя в области проектирования аппаратуры. Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model — компонентная модель объектов), и тех­нологии создания распределенных приложений CORBA (Common Object Request Broker Architecture — общая архитектура с посредником обработки запросов объектов).

Бизнес с нуля. Какой сайт делать? На чём сайт делают? Где заказать сайт? У кого заказать сайт?

Эти технологии используют сходные принципы и разли­чаются лишь особенностями их реализации. Технология СОМ фирмы Microsoft является развитием техноло­гии OLE I (Object Linking and Embedding — связывание и внедрение объек­тов), которая использовалась в ранних версиях Windows для создания состав­ных документов. Технология СОМ определяет общую парадигму взаимодей­ствия программ любых типов: библиотек, приложений, операционной сис­темы, т. е. позволяет одной части программного обеспечения использовать функции службы), предоставляемые другой, независимо от того, функцио­нируют ли эти части в пределах одного процесса, в разных процессах на од­ном компьютере или на разных компьютерах (рисунок 1.7). Модификация СОМ, обеспечивающая передачу вызовов между компьютерами, называется DCOM (Distributed COM — распределенная СОМ).

7.Блочно-иерархический подход к созданию сложных систем

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

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

В свою очередь, используя то же различие связей, можно каждую подсистему разделить на подсистемы и т. д. до самого нижнего «элементарного» уровня, причем выбор уровня, компоненты которого следует считать элемен­тарными, остается за исследователем. На элементарном уровне система, как правило, состоит из немногих типов подсистем, по-разному скомбинирован­ных и организованных.

Зачем нужны Бизнес-каналы? Как зарабатывают KOSMOPOLIT и Olga Ermilova?

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

В природе существует еще один вид иерархии — иерархия «простое-сложное» или иерархия развития (усложнения) систем в процессе эволюции. В этой иерархии любая функционирующая система является результатом развития более простой системы.

Именно данный вид иерархии реализуется механизмом наследования объектно-ориентированного программирования. Будучи в значительной степени отражением природных и технических систем, программные системы обычно являются иерархическими, т. е. обла­дают описанными выше свойствами.

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

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

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

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

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

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

Другими словами, чем больше блок, тем более абстрактным должно быть его описание (рис. 1.8).

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

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

Совокупность языков моделей, постановок задач, методов описаний не­ которого иерархического уровня принято называть уровнем проектирования. Каждый объект в процессе проектирования, как правило, приходится рассматривать с нескольких сторон. Различные взгляды на объект проектирования принято называть аспектами проектирования.

Помимо того, что использование блочно-иерархического подхода делает возможным создание сложных систем, он также: — упрощает проверку работоспособности, как системы в целом, так и от­дельных блоков; — обеспечивает возможность модернизации систем, например, замены ненадежных блоков с сохранением их интерфейсов. Необходимо отметить, что использование блочно-иерархического подхода применительно к программным системам стало возможным только по­сле конкретизации общих положений подхода и внесения некоторых измене­ний в процесс проектирования. При этом структурный подход учитывает только свойства иерархии «целое-часть», а объектный — использует еще и свойства иерархии «простое-сложное».

Источник: studfile.net

Component Business System (CBS) Athena (компонентная бизнес-система «Афина»)

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

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

Концептуально большинство работающих в банках АБС не соответствуют этим требованиям!

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

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

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

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

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

Требования к новой архитектуре банка

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

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

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

Третий слой — транспортный уровень. Здесь требуется 100%-ная настраиваемость c возможностью регулирования и распределения информационных потоков между различными приложениями для фактического объединения их в единую систему с единым управлением.

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

Компонентная бизнес-система (CBS): максимум возможностей в современных условиях

«Кубиками» современной банковской инфраструктуры должны стать адаптивные бизнес-компоненты, удовлетворяющие современным стандартам управления бизнес-процессами, способные бесконфликтно встраиваться в современные IT-ландшафты, образующие в результате единую целостную компонентную банковскую систему.

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

CBS Athena — реализация BPM средствами SOA

Наш новый продукт Component Business System (CBS) Athena (компонентная бизнес-система «Афина») относится к принципиально новому классу систем, реализующих требования BPM в банковской деятельности средствами SOA.

CBS Athena имеет открытую сервисно ориентированную архитектуру (рис. 1), состоящую из наборов гибко конфигурируемых, легко заменяемых разноуровневых функциональных компонентов, и ориентирована на максимальное использование промышленных инструментальных средств (IBM, Oracle и др.), а не на создание их аналогов.

Одно из наиважнейших преимуществ CBS Athena — отделение моделей обслуживания и общей логики бизнеса от технологических особенностей конкретных IT.

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

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

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

Таким образом, при неизменном наборе компонентов могут меняться как бизнес-процессы работы банка, так и состав используемого им ПО, а появление новых компонентов может не затрагивать логику уже существующих. И наоборот, бизнес-процессы могут оптимизироваться при относительно неизменном составе компонентов.

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

Место CBS Athena в банковской инфраструктуре

Специализация и компетентность мирового софтверного рынка сегодня чрезвычайно развиты. Активно развивается SOA, производство серверов приложений, единых сервисных шин предприятий и других программных средств новых поколений. Нотации BPMN и BPEL становятся стандартом de facto, а поддерживающее их ПО производится многими поставщиками.

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

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

CBS Athena по своей сути является гибкой бизнес-ориентированной надстройкой над этим ПО (рис. 2). Имея в своем составе интерфейсы к продуктам сторонних производителей, CBS Athena с минимальными затратами вписывается в индивидуальный IT-ландшафт конкретного банка.

Состав CBS Athena

В состав системы входят:

• Компоненты и сервисы, обеспечивающие реализацию бизнес-процессов банка под управлением внешней BPM-машины.
• IT-сервисы — связующий слой, обеспечивающий низкоуровневую реализацию логики выполнения бизнес-операций.
• Интерфейсы взаимодействия со всеми видами необходимого ПО, используемого банком при построении конечной системы.
• Модели бизнес-процессов, адаптируемые под требования конкретных реализаций BPM-машин.

CBS Athena — бизнесу банка

Стратегические бизнес-преимущества, которые дает банкам применение CBS Athena, следующие:

• Более строгая формализация бизнес-процессов и приведение их к единому стандарту (BPMN).
• Возможности значительного повышения управляемости бизнеса.
• Реализация целостного системного подхода к построению бизнеса и управлению.
• Широкие возможности оптимизации бизнес-процессов на всех уровнях.
• Минимальная зависимость бизнеса от программно-аппаратных платформ и конкретных приложений.
• Строгое подчинение IT-инфраструктуры потребностям банка (бизнес-процессам) как в оперативно-тактическом, так и в стратегическом плане.
• Реальные возможности унификации и оптимизации бизнес-процессов в масштабах крупных филиальных сетей.
• Гибкие возможности формирования разнообразных архитектурных комбинаций.
• Возможность последовательной реализации с оптимизацией инвестиций.

CBS Athena — инфраструктуре банка

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

CBS Athena дает банку не только новый функционал, но и новые возможности управления своими существующими ресурсами за счет использования BPM и SOA. Вместо приспособления инфраструктуры банка под требования конкретной АБС банк сам формирует инфраструктуру, ориентируясь в первую очередь на требования своего бизнеса.

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

Использование BPM позволяет сделать развитие нового функционала более очевидным и полезным для бизнеса. Бизнес становится непосредственным участником процесса, и это позволяет эффективно распределять инвестиции в IT.

Кроме того, CBS Athena позволяет более эффективно и быстро проводить доработки функционала, так как итоговое решение не зажато рамками и требованиями конкретной АБС и имеет множество альтернативных вариантов.

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

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

Источник: www.tadviser.ru

Компонентная технология реинжиниринга бизнес-процессов с использованием системы управления знаниями ( Компонентная технология )

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

Компонентная технология

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

Существующие компонентные технологии в большей степени ориентированы на внедрение корпоративной информационной системы, поддерживающей организационные изменениями в меньшей степени на создание организационной документации (в основном организационное проектирование связано с определением ролевых функций подразделений по использованию КИС). С помощью подобных компонентных технологий реинжиниринг бизнес-процессов сводится к построению модели проблемной области предприятия, проверке реализуемости построенной модели с помощью типовых информационных систем, выбору конкретной типовой КИС и настройке ее программных модулей в соответствии с моделью. Для этого компонентная технология проектирования- должна поддерживать модель типовой КИС, модель проблемной области конкретного предприятия, а также средства поддержания соответствия между ними. Для моделирования проблемной области и последующих конфигураций бизнес-процессов и информационной системы из отдельных компонентов (программных модулей) используется специальный программный инструментарий, например SAP Business Engineering Workbench (BEW) и BAAN Dynamic Enterprise Modeler (DEM).

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

Репозитории компонентной технологии проектирования в общем случае содержит метаинформацию базовой модели функциональности типовой КИС (ссылочной модели в терминологии R/3), типовых моделей определенных классов КИС (референтных моделей в терминологии BAAN) и проектной модели предприятий, получаемой на основе базовой или типовых моделей.

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

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

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

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

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

Использованная литература

1. http://www.dslib.net/mat-metody/komponentnaja-metodologija-reinzhiniringa-biznes-processov-na-osnove-upravlenija.html
2. https://lektsia.com/6x85db.html
3. http://www.studentlibrary.ru/doc/ISBN5279029122-SCN0002.html

• Стратегическая карта
• Стратегическая карта (Структура стратегической карты)
• Внедрение системы сбалансированных показателей
• Автоматизация учета продаж на предприятии ЗАО «Лапкин
• Описание организации ЗАО «НТЦ МИК-ИНФОРМ»
• ключевые факторы успеха (ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ КФУ И ИХ ИСПОЛЬЗОВАНИЕ В УПРАВЛЕНИИ ПРЕДПРИЯТИЕМ)
• Основания и порядок признания забастовки незаконной
• Команда проекта (Формирование команды)
• Language and Literacy
• Компонентная технология реинжиниринга бизнес-процессов с использованием системы управления знаниями (Компонентная технология )
• Структура аппарата районного суда
• Структура аппарата Верховного суда РФ.

При копировании любых материалов с сайта evkova.org обязательна активная ссылка на сайт www.evkova.org

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

Сайт пишется, поддерживается и управляется коллективом преподавателей

Telegram и логотип telegram являются товарными знаками корпорации Telegram FZ-LLC.

Cайт носит информационный характер и ни при каких условиях не является публичной офертой, которая определяется положениями статьи 437 Гражданского кодекса РФ. Анна Евкова не оказывает никаких услуг.

Источник: www.evkova.org