На практикуме по системному мышлению мы познакомились с понятиями “функция“ и “сервис”. Эти понятия разделяют представления разных сторон на одни и те же вещи.
В общем-то функции и сервисы это об одном и том-же: некоторых действиях, которые одна система оказывает для другой.
Когда действия рассматриваем со стороны системы-потребителя то называем их функцией.
Когда действия рассматриваем со стороны системы, которая их производит, то называем их сервис.
Казалось бы, использовали два слова для одного и того же, но это дает возможность осознать и обнажить ту разницу, которая может присутствовать в понимании одного и того же действия с разных сторон.
Функция - то, что востребовано. Эти действия нужны той системе, которая использует исполняющую их систему.
Сервисы - то что предоставляется. Это действия которые могут быть выполнены системой для других систем.
Функции и сервисы похожи на спрос и предложение. С одной стороны кто-то что-то хочет, а с другой стороны ему что-то дают.
Если представить функцию и сервис в виде неких областей или множеств их свойств или качеств, которые располагаются в одном пространстве, то они обязательно должны пересекаться. Т.е. затребованные качества и свойства действия должны предоставляться.
Плохо если требования функции не полностью покрываются возможностями сервиса. Это значит, что часть действий надсистемы, обеспеченная выполнением недостающих функций не будет функционировать.
Для нормального функционирования системы, использующей функции, необходимо чтобы возможности сервиса совпадали с запрашиваемыми или превосходили их.
Для многих систем нормально если превосходство возможностей сервиса над запрашиваемой функцией крайне велико. Часто это программные системы с большим количеством пользователей с разнообразными запросами. Т.е. Несмотря на то, что в общем-то некоторые сервисы могут не пользоваться популярностью, но среди большого количества пользователей найдется значительное количество тех, у которых будет иметься запрос на тот или иной сервис.
Но иногда поддержка сервиса в работоспособном состоянии требует затрат от оказывающей его системы. Так , например отель может предложить размещение в номерах от типа “эконом” до типа “президентский люкс”, а путнику нужен ночлег в стандартном номере и он выбирается один из множества вариантов. Но ведь если путников будет ограниченное количество, то невыбранные номера останутся пустыми и отель понесет убытки.
Для небольших развивающихся систем обеспечения вопрос соответствия запрашиваемым функциям весьма важен. Ведь на реализацию сервиса необходимы трудовые или материальные ресурсы, которые могут быть применены для развития на других направлениях. В случае если сервис будет реализован, но будет не востребован, значит силы были потрачены зря, а этого никто не любит.
Как же сделать так чтобы не зря трудиться? Вопрос волнует многих и однозначного ответа нет. Но есть методы, позволяющие снизить количество затрат.
- Развивать сервисы по потребностям. Вариант хорош когда система, оказывающая сервис, ни с кем не конкурирует. Все просто - делаем то что просили. Недостатком подхода является неприменимость в системах с инициативной разработкой, когда никто не просит что-то сделать, а обеспечивающую систему будут выбирать по набору сервисов;
- Применять гибкий подход к развитию или разработке системы. Наиболее популярен гибкий подход в разработке программного обеспечения. Часто заказчик не в состоянии сформулировать описание системы да и требования при разработке могут меняться, поэтому создание системы происходит поэтапно начиная с наиболее востребованных частей. При создании разработчик получает обратную связь от заказчика или потребителя и имеет представление об их запросах на те или иные сервисы. Метод позволяет лучше реагировать на запрос сервисов, но требует наличия коммуникаций с проектными ролями использующей сервисы системы, что, к сожалению, не всегда возможно.
- Интеграция сторонних сервисов. Не всегда есть смысл что то делать с нуля и стоит посмотреть по сторонам может нужный сервис уже оказывается какой-либо другой системой. Т.е. Если в гостинице нет кухни, а постояльцев нужно кормить завтраком это повод договориться с ближайшим рестораном. Подход часто в долгосрочной перспективе экономически не выгоден и хорош как временное решение для экономии вложений. Скорее всего если сервис будет востребован, то стоит его реализовать в составе системы, но пока это еще не ясно, использование стороннего сервиса сможет помочь выявить запрос на функцию который он будет удовлетворять.
Это нормально если множество сервисов перекрывает множество запрашиваемых функций, так как это предоставляет возможность развития использующей системы или позволяет использовать обеспечивающую систему для разных использующих систем. Тут важно при проектировании не увлечься удовлетворением большого количества несуществующих запросов.