ЭКО для ИТ

Несмотря на модность термина «экосистема», с пониманием ее отличия от привычной «платформы» пока туго. Любим мы красивые слова, а смыслы блуждают. Не могу претендовать на истину, но решил поделиться своим представлением, поскольку в обсуждении на facebook пошли вопросы и мое мнение кому-то показалось нужным.

После монолитных программных продуктов востребованная рынком гибкость породила платформы. Развитие в ИТ идет быстро, конкурировать по всем фронтам сложно. Если платформа востребована, у нее много пользователей, есть шанс нарастить функциональность, привлекая сторонних разработчиков. Для этого можно разработать библиотеку функций (API), обращение к которым позволяет использовать некоторые внутренние сущности платформы, и дать к ним доступ сторонним разработчикам.

Вроде, все привлекательно:

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

Но привлекательность платформы является ключевым фактором привлечения внешних разработчиков– еще неизвестно, кто кому должен платить. Разработчик должен либо полностью довериться платформе и жить только под ней, либо адаптировать свой продукт под разные среды. Не каждый разработчик готов полностью удовлетвориться одной платформой либо разрываться для поддержания продукта одновременно во всех средах. Функциональность API должна развиваться, а менять библиотеки и одновременно развивать функциональность основного продукта платформы непросто. Чем быстрее развитие ИТ, тем менее отвечает платформа задачам развития и конкурентности.

Ответом на увеличение скорости ИТ-разработок и ужесточение конкуренции стали экосистемы. Само слово родом из экологии, биологии– означает существующую и гибко развивающуюся совокупность живых и неживых сущностей. Принципиально важным признаком экосистемы является ее открытость. Каждый ее элемент участвует в естественном отборе: может выжить сам, выжить другого, или съесть, может войти во взаимовыгодные отношения, симбиоз, может уйти, может прийти...

Логично предположить, что, позаимствовав понятие из экологии, сфера ИТ хочет отразить специфические смыслы понятия «экосистема» в проекции на ИТ. Платформа– закрытая система, открываемая дозировано ее владельцем и требующая для существования на ней соблюдения правил написания кода и постоянной адаптации к развиваемой библиотеке. Единственным смыслом привнесения в ИТ понятия «экосистема» я вижу противопоставление ее платформе. Экосистема– открытая система. В чем может быть ее открытость для ИТ?

Главным фактором открытости в ИТ является отсутствие необходимости писать код с оглядкой на внешние требования. Каждый пишет свою программную систему так, как считает нужным. Чтобы вступить в экосистему, достаточно соблюсти правила информационного взаимодействия– протоколы обмена. Никто не разрешает и не запрещает в нее вступать. Чтобы начать взаимодействие, достаточно ознакомиться с протоколами, которые открыто опубликованы. Если работа по протоколам отлажена, программный продукт вступает в экосистему аналогично живым системам в экологии.

Одним из не самых удачных, но наглядных примеров может служить платформенная экосистема, как бы не странно это звучало: «экосистема Apple», «экосистема Windows» и т.п. Открытость этих систем ограничена возможностями соответствующих платформ (и в этом неудачность примера), а открытость в том, что никто не запрещает в нее входить. Протоколами являются все возможности платформ по написанию программного кода– они настолько широки, насколько может позволить соответствующая операционная система, являющаяся платформой.

Правда, стоит дополнительно отметить, что Apple/Windows как «платформа» имеет несколько иной смысл, чем платформа как информационная система. Слова одинаковые, а смыслы несколько отличные. Все же в данном примере правильнее называть Apple/Windows/Linux/Android операционными системами, которые изначально создаются максимально открытыми, хотя их уровень открытости тоже разный. Программный продукт изначально закрыт. Чтобы его открыть, нужно это делать специально.

Более удачным примером могут служить интернет-сервисы, которые не ограничены практически ничем: опубликован протокол, живущий на любой операционной системе– и работай в свое удовольствие. Именно поэтому из семейства интернет-сервисов вытесняются такие протоколы, которые ограничивают возможности подключения. Например, популярный в свое время протокол Flash. Он был подконтролен конкретной компании (значит, она могла в любое время запретить любому внешнему сервису его использование) и успешно работал только на Windows.

Поскольку понятие «платформа» имеет тенденцию разрастаться, такие сервисы тоже начали называть платформами. Какой сервис уместно называть платформой, а какой нет, вопрос тонкий– развивать его здесь я не готов. Понятие расползается, как многие понятия во многих сферах вслед за модой на эффектные названия. Если открывают интерфейсы для доступа сторонним разработчикам, их называют открытыми платформами– open platform.

В этих условиях граница различения между платформами и экосистемами стирается. Поэтому и появился этот текст. Замыливание понятий при заимствовании их из других сфер сегодня происходит повсеместно. Я считаю важным удержание грани между разными терминами, чтобы смысл не терялся:

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

Почему слово «платформа» расширяет сферы покрытия, а «экосистема» используется редко?

• Платформа– нечто основательное, звучит более убедительно даже на уровне подсознательного восприятия.
• Экосистема– нечто нарастающее само, если приживается.

А нарастает экосистема практически везде: в болоте, в озере, в море, в океане, даже около глубоководных серных вулканов, где нет кислорода. И везде разная. Вполне органично строить платформу, на которой нарастет своя экосистема. Богатая или бедная, неважно– какая-то нарастет.

Ключевой вопрос– зачем? Платформу строить зачем?

• Доить, что нарастет, или создать условия для нарастания того, что хочется?
• Машина для сбора, что бог пошлет, или машина для выращивания того, что сам решил выращивать?
• Или для отмывания того, что нарастет, как неизбежность мойки?

Когда строят платформу, хотят или не хотят, на первом месте платформа.

Когда строят экосистему, думают о создании условий именно для нее: платформа это или зонтик, определяется предположениями о потребностях желательной экосистемы.

Для иллюстрации платформенного и экосистемного подхода покажу модели внедрения модных электронных журналов (ЭЖ) и дневников (ЭД).

В большинстве регионов внедрены волевым решением учредителя региональные информационные системы, в которых реализованы функции журналов и дневников. Законность и прочие сомнительные аспекты обсуждать не буду– кому интересно, можете покопаться в моем блоге по ключевому слову и/или на сайте проекта РУЖЭЛЬ. Я этому уделил в свое время большое внимание.

В качестве таких региональных систем используются:

• откровенные платформы,
• монолитные сервисы-платформы,
• совокупности сервисов, которые могли бы быть экосистемами для самых разных ЭЖ/ЭД, но волевым решением учредителя тоже ведут себя как платформы.

Чем отличается «откровенная платформа» от «сервиса-платформы»?

• Первое является программным продуктом, написанным как код в определенной операционной системе, для использования которого сторонними разработчиками нужно обращаться к библиотеке в той же программной среде. Все строго, как написано выше.
• Сервис тоже программный код, web-приложение для работы через стандартные интернет-сервисы. С внешним миром он обменивается по открытым стандартным протоколам. Если бы в него заложили возможность брать данные или вносить из внешних систем, он мог бы стать основой экосистемы. Но этого не стали делать.

Чем отличается одинокий сервис от совокупности сервисов?

Совокупность уже взаимодействует между собой, т.е. в них уже заложены возможности обмена данными. Если их открыть для внешних систем, появилась бы возможность встроиться в общую работу новым информационным системам. В частности, можно было бы разработчикам альтернативных ЭЖ доработать их для работы по этим протоколам– и возникла бы экосистема, в которой каждая школа могла бы реализовать свое право на выбор того ЭЖ, который ей удобнее. Платформу и монолитный сервис под эту задачу адаптировать сложнее.

Я знаю регион, где такую экосистему можно было бы сделать одним росчерком пера: «разрешаю». Я в шоке, но... все «как всегда».

Почему же даже при наличии возможности создать экосистему этого не делают?

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

Мы хотели убедить в удобстве и возможности сделать подобную экосистему

На иллюстрации один слайд из нашей давнишней презентации. Подразумевалось, что нет смысла создавать единое кладбище отметок по всему региону и даже муниципалитету, потому что отметки нужны и важны только в школе, где они порождены, теми, кто их породил и кто с ними работает. На уровне органов управления нужна статистика. Если информационная система для чиновников обращалась бы на едином языке к любым ЭЖ в школах, те могли бы ей отдавать готовые для отчета данные. Эти агрегированные данные никак не зависели бы от той системы оценивания, которая применяется в школе и, тем самым, не ограничивала бы школы в праве выбирать любые системы оценивания.

Другой пример– ЭД. Сегодня любой ЭД намертво привязан в своему ЭЖ– это выжимка из ЭЖ для конкретного ученика. В то же время, ученик сегодня занимается не только в школе, а ЭД, по сути,– это органайзер. Если бы все ЭЖ поддерживали единый протокол обмена данными о заданиях, расписаниях, отметках, на рынке была бы конкуренция мобильных приложений типа «органайзер школьника». Они бы собирали удобным для использования образом в одном месте информацию со всех школ/занятий, которыми занят школьник.

Чтобы построить «Цифровую школу» в логике экосистемы, нужно продумать архитектуру (как и вокруг чего могли бы концентрироваться различные конкурирующие ИТ) и описать протоколы обмена между ними. Нужно создать один или несколько стержневых сервисов и сервис отладки протоколов обмена, чтобы новые игроки не мешали работе систем в процессе отладки работы по протоколам.