Мобилизация корпоративных информационных систем и дилемма инноватора

Если бы лет пять назад вы спросили программиста, будет ли в будущем его приложение работать на андроиде то, в лучшем случае, он счел бы вас эксцентричным фанатом «Звездных войн». Сегодня вопрос предоставления сотрудникам доступа к корпоративной информационной системе с мобильных устройств звучит вполне обыденно. Вопрос не в том, предоставлять ли такой доступ, а скорее – как это сделать. Очевидный ответ на него: разработать для приложений мобильные клиенты – мне представляется нечестным и трудно реализуемым. На протяжении последних пятнадцати лет мы регулярно переписываем свои корпоративные системы. Сначала мы переписывали их в архитектуру клиент-сервер, потом переписывали на Java, затем готовили к проблеме 2000. С появлением серверов приложений мы снова их переписывали.

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

Я не раз писал о том, почему так происходит. Позволю себе повторить это еще один раз, хотя бы вкратце:
Изначально HTTP является stateless протоколом. Т.е. сервер не должен хранить состояние сессии каждого из своих клиентов. Клиент отправляет атомарный запрос, сервер формирует ответ и это все. Такие решения легко масштабируются, предоставляют возможность кэширования данных, в общем, поддерживают распределенную архитектуру. Корпоративные приложения работают не так. Мы запускаем такое приложение, вводим логин-пароль, выбираем в навигаторе группу необходимых объектов, перемещаемся по списку таких объектов, выбираем один из них, редактируем в режиме мастера(wizard), приступаем к другому объекту, к концу рабочего дня закрываем сессию.
Далее, у каждого web-ресурса есть уникальный идентификатор URL. Идентификаторы сообщений в блогах, страниц в википедии, людей в социальных сетях не меняются. Вы можете сохранить гиперссылку в закладках, переслать другу по электронной почте или разместить на своей web-странице. В корпоративных информационных системах таких идентификаторов нет даже для основных данных. Для получения информации по клиенту, сотруднику или услуге вам необходимо проделать все шаги из п.1. Более подробно на эту тему см. сообщения HATEOAS (Hypermedia as the Engine of Application State) и RESTful и Enterprise 2.0

Корпоративные информационные системы разрабатывались для пользователей, что называется «под ключ». И потому работать с ними могут только люди. Никто и не предполагал, что однажды мы захотим встроить существующий функционал в другие системы. Именно поэтому буксует сервис-ориентированная архитектура. API унаследованных приложений просто не могут стать сервисами.

Ответ на вопрос, почему же разработчики корпоративных информационных систем поступают именно так, на мой взгляд, дает гениальная книга Кристенсена Клейтона «Дилемма инноватора. Как из-за новых технологий погибают сильные компании». В ней он рассказывает почему продукты вполне инновационных компаний, являющихся лидерами рынка, имеющих отличный менеджмент, выстроенные бизнес-процессами, разумные принципы принятия решений, вдруг замещаются менее эффективными и недостаточно качественными «подрывными» решениями. И почему, компании даже видя такие инновации, не могут поменять свой продукт. Как «переизбыток качества» (для информационных систем – функционала), требования заказчиков и давление акционеров парализуют творческую активность организаций, лишая их каких-либо шансов противостоять замещающим технологиям. Организации не то чтоб не хотят, они просто не могут этого сделать. Я не буду пересказывать всю книгу, чтоб не портить вам удовольствие от её чтения. Краткий вывод для айтишников – избавляйтесь в своих системах от незадействованных фич.

Ссылку на эту книгу я нашел благодаря заметке 2005 года Web Services and the Innovators Dilemma. Автор рассуждает о том, почему REST может оказаться более востребованным чем SOAP, а микроформаты – чем RDF и OWL. Уже лет десять тема Semantic Web, развиваясь своим путем, остается малоизвестной, а появившаяся в HTML5 Microdata известна уже практически всем. OASIS издает тонны стандартов WS-*, которые никто не использует. Та же ошибка подстерегает тех, кто собирается переписывать своё приложение для мобильных устройств. Дело в том, что варианты использования(use case) приложения на десктопе и на телефоне различны. Пользователь просто не будет делать на телефоне то, что обычно делает на персональном компьютере. Как используется мобильное приложение, я попробовал написать в заметке Mobile Human Task Application

Тем не менее, многие разработчики корпоративных информационных систем уже отправились переписывать свои системы для iOS и Android. По-моему, никто из этих проектов пока еще не возвращался.

Мобилизация корпоративных информационных систем и дилемма инноватора: 4 комментария

  1. Максим, а что Вы предлагаете? 🙂 создать принципиально новую архитектуру ПО, где “мобилизация” приложения или группы приложений (да и не только мобилизация, но и создание любого другого презентационного или интеграционного слоя) представляет собой несложное конструирование на базе открытых протоколов – прекрасная масштабная благородная задача. Боюсь только, что силосные башни будут против 🙂 вот и ищут все компромиссов

  2. Олег, я действительно фанат архитектурного стиля RESTful, жаль что не я его придумал 🙂 В чем Вы абсолютно правы, так это в том, что силосные башни не будут меняться в направление такой архитектуры. Не потому, что они “плохие”. Просто они созданы и развиваются в определенных организационных, технологических и рыночных условиях.

    Потому я и пишу, что их не надо переделывать. Получится вытащить какие-нибудь интерфейсы и данные, ну вот и хорошо 🙂

  3. Да, еще давно я написал где-то в своем блоге:
    – web 1.0 – static web
    – web 2.0 – interactive web
    – web 3.0 – structured web

    Поэтому просто перенести “силосную башню” с унаследованной ОС на Android толку никакого не даст, нужна реализация на новых принципах. В частности, нужна реализация распределенных корпоративных классификаторов и справочников на технологиях, использующих концепции, близкие к HTML Microdata. Уже это много даст и потянет за собой все остальное, так как обработка корпоративных данных базируется на использовании корпоративных классификаторов. К тому же использование HTML Microdata это ключ к тесной интеграции и сближению структурированного и неструктурированного корпоративного (и не только) контента, которые пока еще разделены примерно как Сцилла и Харибда в функционале информационных систем (плывущих между ними :).

  4. Для интенет-систем нужно разделить:
    -данные
    -бизнес-логику
    -web-приложения
    -кеш
    -разметку и клиентские скрипты
    – доставку (CDN).

    Например:
    – данные в отдельной схеме в oracle
    – бизнес-логика – в объектах или пакетах в другой схеме в Oracle – к ней имеют доступ web-скрипты или java
    – web-приложения – например сервера с php, apache, nginx + балансировка
    – кеширование – сервера для хранения статики, шаблонов, mem_cashed сервера (там же хранить сеансы)
    – доставка – например VideoCDN.ru.

    И тогда несложно писать интерфейсы хоть на Java или Delphi толстые клиенты, хоть для iPad, хоть HTML5. Главное, не делать приложения через чур избыточными и понимать, зачем вам нужны все эти гаджеты, как и кем они должны быть использованы. Можно конечно интегрить уже имеющиеся ИС, но вещь неблагодарная. Лучше веб-приложения отделить от корпоративной ИС. Накопленные данные реплицировать в корпоративную ИС в последствии.

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

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