Как сохранить работу распределенной IT-системы в эпоху бизнес-перемен? (Ольга Бенкен, SECR-2017) — различия между версиями

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

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

Мой доклад может быть интересен людям, занимающимся поддержкой и развитием крупных длительно используемых систем, обновление которых представляет из себя комплексную задачу.
</blockquote>

{{VideoSection}}
{{vimeoembed|240325489|800|450}}

{{youtubelink|lRgyWsVEi2k}}


{{SlidesSection}}
[[File:Как сохранить работу распределенной IT-системы в эпоху бизнес-перемен? (Ольга Бенкен, SECR-2017) .pdf|left|page=-|300px]]

{{----}}
{{LinksSection}}
* [http://2017.secr.ru/lang/ru/program/submitted-presentations/how-to-get-rid-of-spaghetti-architecture Страничка доклада на сайте конференции]
<!-- <blockquote>[©]</blockquote> -->

<references/>





<!-- topub -->


{{stats|disqus_comments=0|refresh_time=2017-12-25T21:25:31.903662|vimeo_comments=0|vimeo_plays=8|youtube_plays=0}}

Версия 10:31, 30 декабря 2017

Докладчик

Ольга Бенкен

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

Конечным этапом этого перехода стало создание интеграционного приложения, внедрение которого положило конец “веерным” изменениям в коде компонентов в целью поддержать связность системы, а также позволило

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

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

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

Видео

on youtube

Презентация

Примечания и ссылки

• Страничка доклада на сайте конференции

Plays:8   Comments:0