Продуманное программное обеспечение может оптимизировать бизнес-процессы, обеспечить ценность для пользователей и улучшить функциональность услуг. Существует множество стратегий, которые разработчики могут использовать для проектирования успешных систем для своих пользователей. Сервисная архитектура — это один из подходов, который позволяет конечным пользователям проявлять значительную гибкость при создании программ с полезными приложениями для их бизнеса. В этой статье мы определим, что такое сервисная архитектура, перечислим ее ключевые элементы и приведем несколько примеров того, где вы можете увидеть сервисную архитектуру в использовании.
Что такое сервисная архитектура?
Сервисная архитектура, или сервис-ориентированная архитектура (SOA), — это программный подход, который использует существующие сервисы и приложения для предоставления ценности пользователям. В разработке программного обеспечения архитектура относится к фундаментальным структурам, которые разработчики используют при проектировании программных систем. Архитектура сервис-ориентированных систем позволяет приложениям системы использовать другие доступные сервисы в сети. Поскольку разработчики используют существующие сервисы для создания своих приложений, пользователи могут повторно использовать сервис для создания множества уникальных приложений.
2. Бизнес Архитектура предприятия
Еще один акцент в сервисной архитектуре делается на простоте обслуживания. При таком подходе к проектированию сервисы независимы друг от друга. Это может облегчить их обновление и изменение без вмешательства в функциональность других сервисов. SOA часто может потребовать больших первоначальных затрат, но удобство использования и функциональность системы могут сделать ее привлекательной в различных контекстах. Дополнительным преимуществом сервисной архитектуры является то, что, хотя она позволяет создавать сложные приложения с использованием сервисов из других платформ, она не зависит от поставщиков и платформ, что делает ее доступной для любого пользователя.
Элементы сервисной архитектуры
Существует несколько важных компонентов сервисной архитектуры, в том числе:
Интерфейс приложения
В программировании интерфейс приложения — это основа, которую разработчики используют для взаимодействия с приложением и выполнения запросов конечных пользователей. SOA часто стремится предоставить общедоступный, единообразно определенный интерфейс, который использует методы обнаружения для связи конечных пользователей с соответствующими инструментами и приложениями. Эффективные интерфейсы могут позволить разработчикам программ создавать составные приложения, которые эффективно используют существующие сервисы. SOA использует свободную связь между пользовательскими интерфейсами и автономными сервисами, чтобы уменьшить их зависимость от других технологий, сервисов и платформ.
Сервисы
В данном контексте сервисы относятся к самодостаточным единицам программного обеспечения, которые составляют фундаментальную основу SOA. Используя интерфейс, поставщики услуг могут обеспечить доступность услуг для потребителей услуг. Часто провайдеры создают контракты, которые диктуют, какие сервисы доступны и как провайдеры предоставляют эти сервисы потребителю.
Архитектура бизнеса. Общий обзор. Что это и зачем
В SOA существует два основных вида сервисов:
- Бизнес-услуги: Бизнес-сервисы — это сервисы, выполняющие важные функции, необходимые для автоматизированных бизнес-процессов. SOA может объединять сервисы для удовлетворения различных потребностей бизнеса. Например, розничному бизнесу могут потребоваться приложения, отслеживающие инвентаризацию, доставку и управление клиентами.
- Инфраструктурные сервисы: Инфраструктурные услуги — это услуги, которые сами по себе не обеспечивают ценность, но они предоставляют важную техническую функциональность, необходимую бизнесу для эффективного функционирования процессов. Например, службы аутентификации облегчают выполнение определенных бизнес-функций, но сами по себе не являются ценными.
Безопасность
Еще одним важным компонентом архитектуры сервисов является безопасность. Поскольку услуги поступают из множества источников, обеспечение адекватных мер безопасности может оказаться сложной задачей. Часто разработчикам необходимо использовать несколько систем безопасности для создания контроля доступа и аудита. Это может позволить им видеть инициаторов запросов и убедиться, что системы не будут скомпрометированы.
Процессный уровень
Процессный уровень, или уровень оркестровки, дает возможность разработчикам добавлять новые услуги и приложения к существующим предложениям программы. Процессные уровни способствуют автоматизации, поскольку их цель — объединить услуги в надежные и масштабируемые бизнес-процессы. Слой перед слоем процессов, называемый слоем сервисов, показывает все открытые сервисы до их интеграции. С помощью оркестровки и хореографии услуг поставщики услуг могут создавать единые приложения для своих конечных пользователей.
Управление
Управление может быть особенно важным элементом сервисной архитектуры. Из-за отсутствия связи в SOA эффективное управление может обеспечить адекватное выполнение процессов. Менеджеры могут контролировать сквозные системы для обеспечения надлежащей функциональности и выявления проблем до их возникновения. Поставщики услуг могут внедрить операторов, которые могут измерять производительность, состояние системы и ожидать потенциальных препятствий для обслуживания, таких как ограничения пропускной способности.
Мониторинг деловой активности
Процессный уровень сервисной архитектуры предоставляет поставщикам доступ к отдельным процессам. Отсюда они могут контролировать состояние различных приложений. Хотя это может быть полезной функцией, они не способны оценить сразу несколько аспектов бизнес-процесса. Мониторинг деловой активности может показать поставщикам важную информацию о группе процессов одновременно. Они могут настроить приборную панель, которая записывает отчеты и предоставляет бизнес-оповещения, чтобы они могли более эффективно контролировать свои процессы.
Оценка оперативных данных
Счетчик оперативных данных (СОД) может обеспечить просмотр нескольких услуг в режиме реального времени. Использование ODS позволяет отделить уровни доступа от пользовательских интерфейсов, что делает возможным перемещение сервисов между провайдерами. ODS может быть особенно полезен в архитектуре услуг, поскольку он устраняет необходимость получения данных, таких как списки клиентов или продуктов, из отдельных внутренних служб.
Заинтересованные стороны
Двумя важными заинтересованными сторонами в SOA являются поставщики услуг и конечные пользователи. Обычно обе стороны создают контракт, в котором оговариваются условия их взаимоотношений и ожидания от услуг. Поставщики услуг, как правило, предоставляют пакет конкретных услуг и обеспечивают функциональность своих систем. Конечные пользователи, или потребители услуг, чаще всего пользуются услугами и взаимодействуют с поставщиками, предлагая отзывы, делая запросы и открывая новые способы облегчения бизнес-процессов.
Примеры сервисной архитектуры
Как правило, сервисная архитектура использует веб-сервисы для обеспечения ценности для своих пользователей. Это делает систему доступной для использования в различных приложениях и отраслях. Вот несколько примеров использования сервисной архитектуры:
- Розничные торговцы: Розничные компании могут использовать программы SOA для отслеживания своих запасов, регулирования процессов доставки и управления клиентами.
- Электрические компании: Электрические компании могут использовать архитектуру услуг для интеграции своих систем и рационализации процессов для повышения эффективности.
- Военные: Многие военные подразделения используют SOA для своих систем ситуационной осведомленности или систем безопасности, которые объединяют мониторинг окружающей среды, массовые оповещения и анализ данных.
- Здравоохранение: SOA может помочь поставщикам медицинских услуг управлять данными о пациентах для своих многочисленных клиентов, таких как представители службы поддержки, страховые компании, врачебные кабинеты и пользователи веб-сайтов. Архитектура услуг позволяет провайдерам хранить данные в одном источнике, управляя доступом к ним через множество приложений.
- Приложения для смартфонов: многие приложения для смартфонов требуют сервисной архитектуры для обеспечения множества встроенных функций. Например, если приложение включает в себя GPS-слежение, но само не предлагает эту услугу, команда разработчиков может использовать SOA в качестве решения для интеграции нескольких сервисов в одно приложение.
Ключевые слова:
- indeed.com
- Дмитрий Л
Источник: hr-portal.ru
Что такое сервис-ориентированная архитектура?
Сервис-ориентированная архитектура (SOA) – это метод разработки программного обеспечения, который использует программные компоненты, называемые сервисами, для создания бизнес-приложений. Каждый сервис предоставляет бизнес-возможности, и сервисы также могут взаимодействовать друг с другом на разных платформах и языках. Разработчики применяют SOA для многократного использования сервисов в различных системах или объединения нескольких независимых сервисов для выполнения сложных задач.
Например, несколько бизнес-процессов в организации требуют функциональности аутентификации пользователя. Вместо того чтобы переписывать код аутентификации для всех бизнес-процессов, вы можете создать единый сервис аутентификации и использовать его повторно для всех приложений. Подобным образом, почти все системы в организации здравоохранения, такие как системы управления пациентами и системы электронных медицинских карт (EHR), нуждаются в регистрации пациентов. Эти системы могут вызывать единый общий сервис для выполнения задачи регистрации пациента.
Каковы преимущества сервис-ориентированной архитектуры?
Сервис-ориентированная архитектура (SOA) имеет ряд преимуществ перед традиционными монолитными архитектурами, в которых все процессы выполняются как единое целое. Вот некоторые из преимуществ SOA:
Сокращение времени выхода на рынок
Разработчики повторно используют сервисы в различных бизнес-процессах для экономии времени и затрат. С помощью SOA они могут создавать приложения гораздо быстрее, чем с написанием кода и выполнением интеграций с нуля.
Эффективное обслуживание
Легче создавать, обновлять и отлаживать небольшие сервисы, чем большие блоки кода в монолитных приложениях. Модификация любого сервиса в SOA не влияет на общую функциональность бизнес-процесса.
Улучшенная адаптивность
SOA лучше адаптируется к технологическому прогрессу. Вы можете модернизировать свои приложения эффективно и без лишних затрат. Например, медицинские организации могут использовать функциональность старых систем электронных медицинских карт в более новых облачных приложениях.
Какие основные принципы сервис-ориентированной архитектуры?
Не существует четко определенных стандартных рекомендаций по реализации сервис-ориентированной архитектуры (SOA), однако есть некоторые общие основные принципы.
Обеспечение совместимости
Каждый сервис в SOA включает документы описания, которые определяют функциональность сервиса и связанные с ним условия. Любая клиентская система может запустить сервис, независимо от базовой платформы или языка программирования. Например, бизнес-процессы могут использовать сервисы, написанные как на C#, так и на Python. Поскольку нет прямых взаимодействий, изменения в одном сервисе не влияют на другие компоненты, использующие этот сервис.
Слабая взаимозависимость
Сервисы в SOA должны быть слабосвязанными, иметь как можно меньше зависимостей от внешних ресурсов, таких как модели данных или информационные системы. Они также должны быть статичными, не сохраняя никакой информации из прошлых сессий или транзакций. Таким образом, если вы измените сервис, это не окажет существенного влияния на клиентские приложения и другие сервисы, использующие этот сервис.
Абстрагирование
Клиенты или пользователи сервисов в SOA не обязаны знать логику кода сервиса или детали его реализации. Для них сервисы должны выглядеть как черный ящик. Клиенты получают необходимую информацию о том, что делает сервис и как его использовать, через контракты на обслуживание и другие документы с описанием сервиса.
Степень детализации
Сервисы в SOA должны иметь соответствующий размер и объем, в идеале упаковывая одну дискретную
бизнес-функцию в один сервис. Разработчики могут использовать несколько сервисов, чтобы создать комбинированный сервис для выполнения сложных операций.
Из каких компонентов состоит сервис-ориентированная архитектура?
Существует четыре основные компонента сервис-ориентированной архитектуры.
Обслуживание
Сервисы – это основные строительные блоки SOA. Они могут быть частными (доступными только для внутренних пользователей организации) или публичными (доступными через Интернет для всех). По отдельности каждый сервис имеет три основные функции.
Реализация сервиса
Реализация сервиса – это код, который создает логику для выполнения конкретной функции сервиса, например аутентификации пользователя или вычисления счета.
Контракт на обслуживание сервиса
Контракт на обслуживание сервиса определяет характер сервиса и связанные с ним условия, такие как предпосылки для использования сервиса, его стоимость и качество исполнения.
Интерфейс сервиса
В SOA другие сервисы или системы взаимодействуют с сервисом через его интерфейс. Интерфейс определяет, как вы можете вызвать сервис для выполнения действий или обмена данными. Он уменьшает зависимость между сервисами и заказчиком сервиса. Например, даже пользователи, практически не разбирающиеся в логике кода, могут использовать сервис через его интерфейс.
Поставщик сервиса
Поставщик сервиса создает, поддерживает и предоставляет один или несколько сервисов, которые могут использовать другие люди. Организации могут создавать собственные сервисы или приобретать их у сторонних поставщиков сервисов.
Потребитель сервиса
Потребитель сервиса запрашивает у поставщика выполнение определенного сервиса. Это может быть целая система, приложение или другой сервис. Контракт на обслуживание определяет правила, которым должны следовать поставщик и потребитель сервисов при взаимодействии друг с другом. Поставщики и потребители сервисов могут принадлежать к разным отделам, организациям и даже отраслям.
Сервисный реестр
Реестр сервисов (или хранилище сервисов) – это доступный в сети каталог доступных сервисов. В нем хранятся документы описания сервисов от поставщиков. Документы описания содержат информацию о сервисе и о том, как с ним работать. Потребители сервисов могут легко обнаружить необходимые им сервисы, используя реестр.
Как работает сервис-ориентированная архитектура?
В сервис-ориентированной архитектуре (SOA) сервисы функционируют независимо и предоставляют функциональность или обмен данными своим потребителям. Потребитель запрашивает информацию и отправляет входные данные в службу. Сервис обрабатывает данные, выполняет задание и отправляет ответ. Например, если приложение использует сервис авторизации, оно предоставляет ему имя пользователя и пароль. Сервис проверяет их и возвращает соответствующий ответ.
Протоколы передачи данных
Сервисы взаимодействуют с использованием установленных правил, определяющих передачу данных по сети. Эти правила называются протоколами передачи данных. Некоторые стандартные протоколы для реализации SOA:
• Простой протокол доступа к объектам (SOAP)
• RESTful HTTP
• Apache Thrift
• Apache ActiveMQ
• Служба сообщений Java (JMS)
Вы даже можете использовать более одного протокола в своей реализации SOA.
Что такое ESB в сервис-ориентированной архитектуре?
Линейка корпоративных сервисов (ESB) – это программное обеспечение, которое можно использовать при взаимодействии с системой, имеющей множество сервисов. Он устанавливает связь между сервисами и потребителями сервисов независимо от технологии.
Преимущества ESB
ESB предоставляет возможности связи и преобразования через многократно используемый сервисный интерфейс. ESB можно рассматривать как централизованный сервис, который направляет запросы на обслуживание в соответствующий сервис. Она также преобразует запрос в формат, приемлемый для базовой платформы сервиса и языка программирования.
Каковы ограничения при внедрении сервис-ориентированной архитектуры?
Ограниченные возможности масштабирования
Масштабируемость системы значительно ухудшается, когда сервисы совместно используют множество ресурсов и должны координироваться для выполнения своих функций.
Усиление взаимозависимости
Системы сервис-ориентированной архитектуры (SOA) могут усложняться со временем и развивать ряд взаимозависимостей между сервисами. Их может быть трудно модифицировать или отлаживать, если несколько сервисов вызывают друг друга в цикле. Общие ресурсы, такие как централизованные базы данных, также могут замедлять работу системы.
Единая точка отказа
Чтобы реализовать SOA с ESB, последняя создает единую точку отказа. Это централизованный сервис, что противоречит идее децентрализации, за которую выступает SOA. Клиенты и сервисы вообще не смогут взаимодействовать друг с другом, если ESB выходит из строя.
Что такое микросервисы?
Архитектура микросервисов состоит из очень маленьких и полностью независимых программных компонентов, называемых микросервисами, которые специализируются и фокусируются только на одной задаче. Микросервисы взаимодействуют через API, которые представляют собой правила, создаваемые разработчиками, чтобы позволить другим программным системам взаимодействовать с их микросервисом.
Архитектурный стиль микросервисов лучше всего подходит для современных сред облачных вычислений. Они часто работают в контейнерах – независимых программных единицах, которые упаковывают код со всеми его зависимостями.
Преимущества микросервисов
Микросервисы являются независимо масштабируемыми, быстрыми, переносимыми и не зависящими от платформы – это характеристики, присущие облаку. Они также являются развязанными, что означает, что они практически не зависят от других микросервисов. Для достижения этой цели микросервисы имеют локальный доступ ко всем необходимым им данным вместо удаленного доступа к централизованным данным, к которым также обращаются и используют другие системы. Это приводит к дублированию данных, которое микросервисы компенсируют производительностью и гибкостью.
Сравнение SOA с микросервисами
Архитектура микросервисов – это эволюция архитектурного стиля SOA. Микросервисы устраняют недостатки SOA и делают программное обеспечение более совместимым с современными облачными корпоративными средами. Они являются легко управляемыми и благоприятствуют дублированию данных в противовес обмену данными. Это делает их полностью независимыми с собственными протоколами связи, которые открываются через облегченные API. По сути потребители должны использовать микросервис через его API, что устраняет необходимость в централизованном ESB.
Как AWS поможет вам реализовать микросервисы?
AWS – это отличное место для создания современных приложений с использованием модульных архитектурных моделей, бессерверных операционных моделей и гибких процессов разработки. Мы предлагаем наиболее полную платформу для создания высокодоступных микросервисов для обеспечения работы современных приложений любого масштаба и объема. Например, вы можете выполнять следующие действия:
• Создавать, изолировать и запускать безопасные микросервисы в управляемых контейнерах для упрощения операций и снижения накладных расходов на управление.
• Использовать AWS Lambda для запуска ваших микросервисов без инициализации и управления серверами.
• Выбирать из 15 реляционных и нереляционных баз данных AWS, специально созданных для поддержки архитектуры микросервисов.
• Легко отслеживать и контролировать микросервисы, работающие на AWS, с помощью AWS App Mesh.
• Отслеживать и устранять неполадки сложных взаимодействий микросервисов с AWS X-Ray.
Микросервисы на AWS помогают быстрее внедрять инновации, снижать риски, ускорять время выхода на рынок и уменьшать совокупную стоимость владения. Создайте аккаунт AWS и начните работу с SOA и микросервисами уже сегодня.
Источник: aws.amazon.com
Бизнес-архитектура экосистемы банка: как построить и что внутри
В предыдущей статье мы указали на то, что для сохранения на рынке в течение ближайших 5 лет банкам необходимо построение современной бизнес-архитектуры и как цель максимум — превращение в экосистему.
Рассмотрим ключевые компоненты и сервисы экосистемы (см. Табл. 1), которые составляют главное конкурентное преимущество. Для крупных экосистем они должны принадлежать банку (полностью или в рамках контрольной доли участия). Для средних региональных экосистем сервисы могут включаться на условиях стратегического партнёрства, без участия банка в собственности.
| 1.1. | Телекоммуникационная компания, оператор связи | + | — |
| 1.2. | Интернет-компания * | + | — |
| 1.3. | Сервис Такси | + | — |
| 1.4. | Сервис Картографический (геоинформационный) | + | — |
| 1.5. | Логистика (курьеры, почта) | + | — |
| 2.1. | Сервис Страхование | + | + |
| 2.2. | Сервис Доставка еды | + | + |
| 2.3. | Сервис Развлечения (кино, музыка) | + | — |
| 2.4. | Сервис Образование | + | + |
| 2.5. | Сервис Здоровье | + | + |
| 2.6. | Сервис Устройства и ассистенты | + | — |
| 2.7. | Сервисы для недвижимости (уборка, дизайн, ремонт) | + | + |
| 2.8. | Сервис Онлайн покупки | + | + |
| 2.9. | Единая подписка на все сервисы | + | + |
| 3.1. | Сервис Облачная бухгалтерия | + | + |
| 3.2. | Сервис ЭДО ЭЦП с контрагентами | + | + |
| 3.3. | Подключение к Marketplace и SmartMarket (онлайн площадка для продажи продуктов и услуг, в том числе через приложения партнёров) | + | + |
| 3.4. | Сервис Безопасность | + | + |
| 3.5. | Облачные ИТ-сервисы | + | + |
* Под интернет-компанией подразумевается компания, которая предоставляет все возможные интернет-сервисы, включая крупные интернет-порталы: онлайн объявления (авто, недвижимость, товары вторичного рынка, работа), поисковая система, электронная почта, облачные хранилища данных, агрегаторы новостей, тематические блоги, календари, мессенджеры и много другое.
Вариантов построения крупной экосистемы (на федеральном уровне) два:
- Объединяются крупные телекоммуникационная компания + интернет-компания, создают или приобретают необходимые дополнительные сервисы, затем создают всё необходимое для работы банка и получают банковскую лицензию.
- Крупный банк создаёт или приобретает все необходимые сервисы из Табл. 1.
Конечно, это длительный путь, который занимает не один год. Но уже есть примеры известных банков России, СНГ, Евросоюза и США, которые активно идут по этому пути и приближаются к поставленной цели. Конкуренция экосистем и консолидация (объединение) бизнесов — это главный мировой долгосрочный тренд.
В предыдущей статье было выдвинуто предположение, что в России через 5 лет будет 10 банковских экосистем. Делаем уточнение: среди 10 будет 4 крупных (на федеральном уровне) и 6 средних (в регионах). Возможно, количество средних немного увеличится.
Для средних региональных банков отличным вариантом будет создание региональной экосистемы с учётом следующих факторов, которые позволят конкурировать с крупными экосистемами:
- максимальное вовлечение местных компаний (малого и среднего бизнеса региона) для реализации комплекса сервисов, интегрированных с банком;
- активное взаимодействие с органами власти региона, интеграция с государственными региональными и муниципальными услугами;
- интеграция с крупными системообразующими компаниями региона, в первую очередь в рамках зарплатных проектов и связанных с ними продуктов (услуг).
Ключевые особенности экосистемы банка
- В США и европейских странах нарастает тенденция (особенно у молодого поколения) длительного пользования продуктами вместо их приобретения в собственность. Приведём примеры.
- Лизинг мобильного телефона на 1–2 года (Phone leasing programs) с возможностью обмена на новую версию, вместо его покупки. Не нужен потребительский кредит.
- Такси или каршейринг (Carsharing) вместо покупки автомобиля. Не нужен автокредит.
- Длительная аренда апартаментов вместо покупки квартиры. Не нужна ипотека.
- Тесная интеграция сервисов между собой, единые интерфейсы, сквозные идентификаторы пользователей, наличие супер-приложения (superapp), объединение «личных кабинетов» из разных сервисов.
- Анализ и управление большими данными (Big Data), системы искусственного интеллекта работают для того, чтобы взаимодействие с клиентом было максимально персонифицированным, удобным, высококачественным и многофункциональным.
Экосистема будет знать о человеке всё: делает ли он ремонт, есть ли у него дети, автомобиль, какие у него предпочтения в продуктах, собирается ли он в путешествие, какие фильмы / передачи и в какое время обычно он смотрит, даже геолокация и маршруты передвижения (если в экосистему входит телекоммуникационная компания). - Наличие единой подписки и скидок на все сервисы экосистемы, которая удерживает клиента и делает экономически неэффективным использование сервисов от «чужих» экосистем и компаний.
- Финансовая модель экосистемы подразумевает, что величина прибыли всей экосистемы важнее прибыли отдельного сервиса. Т.е. какой-то сервис может вносить существенный вклад в удержание клиента в экосистеме и повышение лояльности, но при этом не иметь высокой прибыли.
Перечисленные сервисы выходят за рамки стандартных банковских продуктов и услуг, поэтому должны быть обязательно встроены в экосистему банка, иначе банк потеряет рынок.
Компоненты бизнес-архитектуры экосистемы
У каждого компонента (сервиса) экосистемы (в том числе банка) разрабатывается своя бизнес-архитектура в отдельной базе данных. Потому что каждый компонент (сервис), например, такси, телекоммуникации, страхование, обычно является отдельной компанией (юрлицом) со своей стратегией, бизнес-процессами, организационной структурой и т. п. Исключение составляют только небольшие сервисы.
Бизнес-архитектура экосистемы в целом представляет собой управленческую надстройку (см. Рис. 1), главная задача которой — это единое управление всеми сервисами и их интеграция.
- Этап 1. Разработка бизнес-архитектуры банка (стандартный банковский бизнес).
- Этап 2. Разработка бизнес-архитектур сервисов, которые включаются в экосистему.
- Этап 3. Разработка бизнес-архитектуры экосистемы банка (т. е. объединение всех сервисов и управление ими).
Перечислим главные компоненты бизнес-архитектуры экосистемы:
- Стратегия. Включает: стратегические карты, дерево целей и показателей (например, по BSC/KPI).
- Дерево бизнес-процессов и графические модели (см. Рис. 2). Более подробная информация и примеры представлены в источнике [1].
- Организационная структура, ролевая модель (см. Рис. 3).
- Библиотека документов. Включает: нормативные документы и формы документов, положения о подразделениях и должностные инструкции, технические документы и т. п.
- Дополнительные модели: операционные риски, проекты, продукты и услуги, материальные ресурсы и т. п.
Большим самостоятельным блоком является ИТ-архитектура экосистемы, которая должна быть проработана максимально качественно и детально. Но её рассмотрение не входит в тему настоящей статьи. Более подробная информация и примеры представлены в источнике [2].
Рис. 1. Бизнес-архитектура экосистемы банка
Рис. 2. Бизнес-процессы экосистемы банка
Рис. 3. Организационная структура экосистемы банка
Инструменты для разработки экосистемы банка
Самым распространённым в России программным продуктом для разработки бизнес-архитектур является система Business Studio. Вместе с ней также внедряются следующие дополнения:
- «Комплексная типовая бизнес-модель банка (финансовой организации)» [3]. Предоставляет следующие практические выгоды и возможности.
- Значительно сократить затраты времени и финансов на реализацию проектов и задач организационно-корпоративного развития. Например, разработка и реализация стратегии, описание и оптимизация бизнес-процессов, построение бизнес-архитектуры в целом, оптимизация численности персонала и много другое. Т. е. не разрабатывать с нуля необходимые модели, документы и базы данных, а использовать типовые как образец.
- Благодаря Бизнес-модели большую часть проектов и задач можно выполнить собственными силами, т. к. в ней содержатся простые и понятные методики для каждой области менеджмента, подкреплённые примерами.
- Быстро и качественно обучить бизнес-аналитиков, методологов, ИТ-специалистов.
- Минимизировать риски при построении систем управления и реализации проектов за счёт уже апробированных и зарекомендовавших себя на практике решений.
- Внедрить в деятельность банка новые идеи и успешные практики из банковской отрасли, посмотреть на своём компьютере, как работают конкуренты со всеми деталями и подробностями.
- Модуль «Process Optimizer: система анализа и оптимизации бизнес-процессов» [4].
Позволяет решить следующие задачи по оптимизации бизнес-процессов и развитию банка. - Оптимизировать бизнес-логику процессов. Выявить наиболее проблемные бизнес-процессы, найти в них слабые места и причины неэффективности.
- Улучшить показатели KPI по следующим группам: время выполнения и трудоёмкость бизнес-процессов, результативность (объём выхода бизнес-процессов), операционная эффективность, качество, издержки (себестоимость бизнес-процессов), фрагментарность.
- Оптимизировать трудовые ресурсы бизнес-процессов на основе расчёта численности сотрудников (исполнителей).
- Выбрать лучшие сценарии выполнения бизнес-процессов на основе сравнительного анализа и поддержки принятия решений.
- Разработать планы по развитию и повышению уровня зрелости бизнес-процессов.
Источники информации:
- Исаев Р.А. 22 практических метода для достижения совершенства процессов и бизнес-архитектуры. Электронное пособие.
- IT Architect: система управления ИТ‑архитектурой.
- Комплексная типовая бизнес-модель банка (финансовой организации).
- Process Optimizer: система анализа и оптимизации бизнес-процессов.
Источник: www.businessstudio.ru