Если бы лет пять назад вы спросили программиста, будет ли в будущем его приложение работать на андроиде то, в лучшем случае, он счел бы вас эксцентричным фанатом «Звездных войн». Сегодня вопрос предоставления сотрудникам доступа к корпоративной информационной системе с мобильных устройств звучит вполне обыденно. Вопрос не в том, предоставлять ли такой доступ, а скорее — как это сделать. Очевидный ответ на него: разработать для приложений мобильные клиенты – мне представляется нечестным и трудно реализуемым. На протяжении последних пятнадцати лет мы регулярно переписываем свои корпоративные системы. Сначала мы переписывали их в архитектуру клиент-сервер, потом переписывали на 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. По-моему, никто из этих проектов пока еще не возвращался.