Трансформация ИТ: сервисная архитектура и интеграция

47702335-33ad-c494-7ae5-98bbcc7ac027Десять лет прошло с момента публикации аналитиком компании Gartner Ефимом Натисом (Yefim V. Natis) статьи Applied SOA: Conquering IT Complexity Through Software Architecture. Это статья довольно быстро была переведена на русский язык и вышла в журнале «Открытые системы» под заголовком Покорение сложности ИТ. Примерно в это же время в отечественных компаниях начались разговоры про сервис-ориентированную архитектуру,  интеграционные среды, а чуть позже трансформацию ИТ. За прошедшие десять лет мы узнали множество новых слов: облачные вычисления, социальные сети, мобильные приложения и даже большие данные,  но так и не научились контролировать сложность корпоративных информационных систем. Давайте отойдем немного назад и попробуем разобраться почему

Сложность(IT complexity) — это мера нашей неспособности понимать, использовать, сопровождать и развивать ИТ-среду предприятия. В статье приводятся следующие причины возрастания IT complexity:

  • Разрозненные унаследованные системы. Многим организациям достались в наследство разработанные независимо друг от друга и автономно используемые системы. Большая их часть была построена без малейшего учета будущих потребностей в интеграции и совместном или многократном использовании информации. Они характеризуются недостаточной открытостью, плохой способностью к координации и взаимодействию.
  • Неодолимая тяга к инновациям. Непрерывные инновации поддерживают конкурентоспособность предприятия, но повышают сложность ИТ-среды (увеличивают технический долг). Эта тенденция особенно сильно проявляется, когда постоянный приток новых систем является следствием отчаянного стремления к нововведениям. Хорошие системы «улучшаются» слишком быстро ради погони за очередной модной новинкой.
  • Давление администрации. ИТ-отделы находятся под постоянным давлением, вынуждающим их как можно быстрее достигать большего с меньшими затратами. Синдром «больше, быстрее, дешевле», естественно, ведет к появлению плохо спланированных, второпях спроектированных и недоделанных систем.
  • Устаревание профессиональных знаний. Часть программистов находится в постоянном поиске новых знаний и навыков, но большинство из них, погрязнув в рутинной работе, постепенно отстают от рынка в отношении навыков и кругозора. Такие «устаревшие» инженеры используют новые технологии «по старинке» и создают системы, не отвечающие ожиданиям.
  • Слияния и приобретения. Реорганизации компаний создают огромную нагрузку на ИТ-отделы. Им нередко приходится отказываться от долгосрочных архитектурных инициатив и без надлежащей подготовки переключать технические средства и сотрудников на незнакомые работы.
  • Политика. Принятие технологических решений часто мотивируется соображениями, связанными с внутренней политикой компании, а не с техническими свойствами или архитектурными достоинствами. Личные интересы поставщика также стимулируют появление технологий, помогающих ему никак не меньше, чем пользователям.

Для решения проблемы сложности корпоративных информационных систем в статье рекомендуется придерживаться следующих принципов:

  1. принцип «черного ящика» — инкапсулируй;
  2. принцип «луковицы» — расслаивай и специализируй слои;
  3. «коммунальный» принцип — уважай и интегрируй;
  4. принцип «городского планирования» — формируй композитные приложения.

Далее в статье дается пояснение этих принципов. Первый принцип говорит о необходимости разработки сервисов. Мне довелось слышать от многих организаций декларации о переходе к сервис-ориентированной архитектуре. Но, ни в одной из них я не видел, чтоб это как-то повлияло на регламенты разработки информационных систем, инструкции по управлению изменениями или положения о жизненном цикле. Невозможно разрабатывать сервисы или композитные приложения, если в ваших процедурах написано, что вы создаете автоматизированные системы. Это не работает. Если целью проекта является разработка и ввод в эксплуатацию информационной системы, которая станет потом основным объектом процесса эксплуатации и поддержки, то кроме новых монолитных систем вы ничего и не получите. Это так же, как при внедрении итерационного подхода: «Вы используете гибкие методологии разработки? Да, конечно. Мы используем SCRUM. Каждый год, 31 декабря, в рамках процесса бюджетного планирования мы с друзьями выбираем из портфеля заявок те, что будем реализовывать в следующем спринте и в течении наступившего года стараемся их реализовать».

Второй принцип в дальнейшем развился в так называемый pace layer approach.  А третий и четвертый принцип это как раз про композитные приложения и стратегию ИТ трансформации

compositeintegration

Многие организации пытались реализовать архитектуру, изображенную в нижней части этой картинки. Мало у кого это получилось сделать. Обычно, процесс замены старых «плохих» приложений на новые выглядит примерно так. После ряда серьезных проблем с существующим приложением, визитов консультантов и вендоров, а так же смены руководства в подразделении заказчика, организация декларирует, что больше терпеть нельзя и на самом высоком уровне принимает твердое решение о замене старой системы. Инициируется проект. Аналитики идут описывать существующие бизнес-процессы, а заказчики встречаться с вендорами и отсматривать новые технологические решения. Примерно через полгода становиться очевидным, что функционала в унаследованном приложении очень много и только на его описание уйдет год, другой. Уже задокументированные процессы тем временем начинают меняться, да и со старым приложением не все так однозначно – кто-то в ИТ отделе сумел его немного подремонтировать и работает оно не так плохо, как это казалось раньше. Но процесс запущен, а значит, решения из архитектурной плоскости перешли в область управления. И вместо вопроса «Как?»  нас теперь больше интересует «Кто виноват?» и «Что делать?». В некоторый момент принимается решение действовать по схеме с верхней части рисунка. Т.е. не переписывать сразу все, а реализовать 20% самых важных и востребованных функций, а остальные оставить пока в старой системе. О том, чем это закончится см. заметку  Модель основных понятий бизнес-анализа. Ну а дальше как с ремонтом, который нельзя закончить, а можно только остановить.

Почему сразу не действовать по схеме с нижней части рисунка? Справедливости ради надо отметить, что десять лет назад технологий, позволяющих реализовать такую архитектуру, еще не было. Интеграционные среды были ориентированы на создание SOAP веб-сервисов, не пригодных для создания интероперабельных решений и удручающих с точки зрения производительности (см. Зачем организациям Enterprise Service Bus). Это теперь принято называть устаревшей, RPC-style сервис-ориентированной архитектурой. Этим сегодня уже никто не занимается кроме ИТ-рекрутеров, тщетно пытающихся заполнить вакансии инженеров по ESB со знанием стандартов WS-*. Технологиям потребовалось время, чтоб научиться реализовывать такую архитектуру. Облачные платформы содействовали появлению масштабируемых приложений с автоматическим развертыванием отдельных узлов. Или, по крайней мере, пониманию того как делать такие решения. Мобильные приложения показали, что наши старые программные интерфейсы никуда не годятся.  Решения для социальных сетей помогли окончательно выдавить бизнес-логику из уровня представления. Обновленная картинка теперь выглядит так:

264171_0003

Подробнее см. прошлогодний отчет Gartner Software-Defined Architecture for Applications in Digital Business, вебинар Use Software-Defined Application Architecture for Digital Business Solutions или интервью на InfoQ A New Style Is Emerging in the Enterprise: Software-Defined Architecture

Интеграционные шины превратились в брокеры программных интерфейсов (API Gateway), сервера приложений в частные облачные платформы, сервисы в микросервисы и т.д. Основные свойства современной интеграционной платформы:

  • Масштабирование за счет использования облачных платформ.
  • Автоматическое развертывание.
  • Безопасное внесение изменений. Новый релиз не заменяет старые компоненты. Они запускаются в общей виртуальной среде рядом со старыми, а брокер начинать перенаправлять на них часть запросов. При необходимости, тут же переключаемся на предыдущий релиз. Тот же подход в работе с данными. Никто не update-ит записи в базе данных. Изменение состояния объекта порождает новую запись. Текущее представление набора состояний, необходимое для тех или иных целей, формируются на лету в отдельных хранилищах.
  • Разделение команд и запросов. Команды выполняются асинхронно и не блокируют вызвавшие их системы. Выборки для запросов предварительно формируются, а сами запросы не влияют на состояние объектов системы.
  • Единый мониторинг бизнес-процессов в режиме реального времени
  • Централизованное управление доступом и нагрузкой

Однако с приходом новых технологий старые культурные и организационные вопросы сами по себе никуда не ушли. Задача управления сложностью, как и раньше, является не общей проблемой организации, а головной болью ИТ-отдела. Проекты по окончательному и бесповоротному построению глобального «светлого будущего» тоже никуда не ушли. По мере увеличения количества центров принятия решений в организациях, таких проектов с каждым годом становится все больше и больше. Данные и функционал остаются «заблокированными»  в границах унаследованных информационных систем, а компетенции и знания – в границах структурных подразделений.

Реклама

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s