SOA обманула аналитиков

Под таким заголовком прошел очередной круглый стол CNews посвященный сервис-ориентированной архитектуре. Я так и не понял, кто и каким образом подчитал, что SOA-решения продаются существенно лучше прогноза. Но дело не в этом. Термин SOA по-прежнему жив, по крайней мере, в нашей стране. О нем действительно продолжают говорить, а значит эта тема до конца не раскрыта. Потому, позволю себе еще один «подход к снаряду».

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

Во-первых, сервис это нечто принимающее и обрабатывающее запросы. Модуль понятие статическое. На картинке он может вообще висеть в пустоте, без стрелок, олицетворяя факт своего существование. Сервис же он работает. Хорошо работает или плохо – другой вопрос. Для того чтоб это понять, есть второе отличие сервиса – сервисный контракт. Соглашение о том, какие запросы и как часто принимает сервис, насколько хорошо их отрабатывает и т.д. Кстати, и в связи с этим, сервис не обязан существовать вечно и работать так же хорошо как в первый день своего творения. Денег [клиент] не заплатил и сервис выключили. Ну и в третьих сервис в SOA это бизнес-сервис. Т.е. он не просто работает, а приносит какую-то ощутимую для клиента пользу. Про сервис мы знаем не только то, что он делает, но и зачем он это делает.

А теперь внимание вопрос архитекторам! Где вот эта новая архитектура, построенная из сервисов. В каком инструменте, с использованием какой нотации её рисовать. Где этот замечательный язык моделирования, который избавит нас от необходимости рисовать разные диаграммы (одну с серверами, другую с компонентами, третью с классами, а четвертую с процессами). Вопрос риторический. На просьбу показать просто архитектуру практически любой ИТ-шник способен предоставить ту или иную картинку. Но если нахмурить брови и строгим голосом спросить: «А где же здесь сервисы? Вы мне какую архитектуру принесли, сервис-ориентированную или как?!»…  Скорее всего, в окружающем пространстве повиснет недоуменное молчание.

SOA обманула аналитиков: 3 комментария

  1. Последние полгода детально изучаю и адаптирую спецификацию ArchiMate. Для описания архитектуры… подчеркиваю, архитектуры… стандарт очень даже неплохой. Спецификация открыта, можно взять и пользоваться. Можно рисовать в MS Visio, но очень неудобно. Есть бесплатный инструмент Archi (лежит на том же сайте, где и спецификация). Но он все же слабоват. Лучше (гораздо удобнее и функциональнее) использовать для целей описания коммерческие решения.
    Через этот стандарт красной нитью проходит понятие сервиса с уровня бизнес-архитектуры до уровня инфраструктуры (читай серверов и экземпляров приложений/баз данных). Но кроме этого стандарт ArchiMate красив сам по себе и понятен.
    Только не нужно пытаться его сразу перекроить и опустить до уровня CMDB. И да прибудет вам счастье, Максим. :)))

    1. Мы тоже позанимались немного ArchiMate-ом. Всем департаментом разбирали пример фантасмогорического госпиталя, с грехом пополам поняли 🙂 Впечатление, что идея правильная. А как приживется на практике – посмотрим

      1. Есть еще одна, не менее занятная книга, с описанием применения ArchiMate с примами ветрянных электрогенераторов, в которой занятно совмещен язык электрических схем с языком системной архитектуры.
        В книге с госпиталем много небольших отклонений от стандарта. Мне же пока удается удерживаться в прокрустовом ложе стандарта.
        Идея языка понятна одновременно для бизнеса и для айтишника. Она дает ту саму единую и связанную картинку, когда тянешь за один узел на уровне бизнес-архитектуры и при этом вслед из горы объектов других уровней (прикладного и технологического) поднимается гроздь объектов, прямо или косвенно связанных с родительским объектом. Для осознания и начала практического использования этого стандарта потребуется значительная ломка сознания и время. Быстро не получится.
        Особенно угнетает этот стандарт в части описания бизнес-процессов. После нотации eEPC эта представляется полным … пейджером. Но приходится терпеть неудобства в частностях ради гармонии в целом. 🙂

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *