были описаны основные инструменты для интеграции систем (корпоративная сервисная шина, XML-сообщения);
был смоделирован в нотации EPC 1 бизнес-процесс, требующий интеграции 3 систем посредством шины и веб-сервисов;
были даны описание и оценка точке интеграции по данному процессу;
были приведены фактические показатели, которые можно оптимизировать на счет SOA;
были приведены аргументы, почему SOA подход эффективен.
На основании всего изложенного можно еще раз заключить, что сервисно-ориентированная архитектура является разумным подходом к организации систем и приложений в компании. По результатам проведенного анализа можно также предположить, в каких ситуациях такой подход имеет смысл, и предложить несколько рекомендаций компаниям, которые рассматривают переход на SOA.
Прежде всего, переход к такой архитектуре имеет смысл в компании, где велико количество используемых систем, т.е. бизнес достаточно масштабный и диверсифицированный. Несмотря на то, что точную оценку количества систем, при которых SOA начинает быть эффективной, дать сложно в виду разной деятельности компаний и их бизнес-потребностей, можно сказать, что компании подходит SOA по нескольким признакам. Как правило, такая архитектура упрощает жизнь процессно-ориентированным компаниям, в которых процессы протекают «сквозь» функциональные подразделения. В вертикальных компаниях часто используется определенный набор приложений, с которым работают внутри одного департамента, и циркуляция информации и происходит, в основном, внутри него. В таких компаниях потребность в информационном обмене между системами и поддержании актуальности данных в смежных системах минимальна. Кроме того, очень важна квалификация персонала и ИТ-специалистов в компании: при отсутствии таковых SOA может оказаться слишком затратным проектом.
Переход также имеет смысл для бизнеса, развивающегося в динамичной индустрии (напр. в сфере информационных технологий), в которой часто возникают потребности в новых решениях, и для быстрого перехода на новые приложения необходима гибкость архитектуры. Более того, для ИТ компании SOA архитектура является своего рода рекламой высокой технологичности и демонстрацией профессионализма, что может привлекать клиентов и подталкивать их к сотрудничеству с такой компанией. Однако, такой переход стоит предпринимать в компании с четко сформулированным обоснованием необходимости переходи и при условии достаточной информационной грамотности и заинтересованности кадров. До перехода на такую архитектуру компаниям можно рекомендовать следующее:
оценить жизненный цикл компании. Если бизнес малый, то переходить на SOA нецелесообразно, поскольку переход представляет собой долгосрочный ИТ-проект, длительность которого может превышать срок жизни компании до ее ликвидации;
провести анализ и, при необходимости, реинжениринг бизнес-процессов для понимания, какие системы несут определенную функциональность в архитектуре;
обеспечить достаточную пропускную способность сети, доступность серверов;
убедиться в целостности и адекватной структуре хранения данных, приемлемой для получения данных сервисами;
обозначить фрагменты функционала систем, которые можно представить в виде сервисов;
собрать квалифицированную проектную команду для перехода, главную роль в которой отвести системным и бизнес-аналитикам;
провести психологическую подготовку персонала к предстоящему переходу, сформировать у них понимание эффективности перехода.
При соблюдении предложенных рекомендаций переход можно будет провести
максимально оперативно и в скором времени оценить в работе эффективность такой
архитектуры. К сожалению, затратную оценку на первоначальном этапе (даже без
учета альтернативных затрат) провести достаточно сложно, поскольку концепции
бизнеса меняются быстро, и порой приходится разрабатывать больше сервисов и
интегрировать больше систем, чем изначально планировалось. Однако, в данной
работе доказано, что переход на SOA
однозначно приведет в снижению временных показателей и общей гибкости
архитектуры, а также поможет разгрузить серверную нагрузку. Так или иначе, в
области исследования сервисно-ориентированной архитектуры может быть сделано
еще много открытий, которые помогут компаниям скорее решиться на переход к этой
модели и сделать этот переход наиболее оптимальным.
1. Portier B. Service, Architecture, Governance, and Business Terms [Электронный ресурс].-URL: https://www.ibm.com/developerworks/webservices/library/ws-soa-term1. (Дата обращения: 22.04.2017).
. SOA и Web-сервисы для новичков [Электронный ресурс]. - URL: https://www.ibm.com/developerworks/ru/webservices/newto/. (Дата обращения: 25.02.2017).
. SOA Архитектурные особенности и практические аспекты. [Электронный ресурс]. - URL: #"896682.files/image006.gif">
Организационная структура Компании
Приложение 3
Схема процесса Согласование договора в нотации EPC
Приложение 4
Интеграционная блок-схема процесса Согласование договора, шаг Формирование