Нематериальный класс

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

В 2005 году Microsoft запустила SQL Server 2005 – последнюю версию своего сервера баз данных RDBMS. Версия 2005 года сменила версию 2000 года, которая отслужила свое. От Microsoft как от ведущего игрока индустрии требовалось поддерживать продукты на протяжении десяти лет после их ввода в эксплуатацию. Таким образом, поддержка SQL Server 2000 должна была продолжиться до 2010 года. Это давало клиентам пятилетнюю отсрочку на замену кода, несовместимого с новыми версиями платформы, – до 2005-го или даже 2010 года. Следовательно, в 2005-м или 2006 году замена кода базы данных – хранимые процедуры, код хранения объектов – не первоочередная задача. Издержек из-за отсрочки в эти годы не произойдет. Но со временем, пока код не изменяется, возможные издержки нарастают. Становится все сложнее работать с другими продуктами, поскольку их обновленные версии требуют обязательной совместимости с SQL Server 2005. Все больше факторов побуждают перейти на новую платформу. К 2009 году вопрос стал неотложным, поскольку вскоре Microsoft собиралась прекратить поддержку предыдущего продукта, и если не произвести обновление, то бизнес останется со старыми машинами и не поддерживаемыми больше операционными системами и соответствующей инфраструктурой. Если это слишком большой риск, то код необходимо обновить. Проблема замены платформы встречается довольно часто: команды разработки ПО сталкиваются с ней постоянно. Всегда есть желание сразу начать работу и вовремя ее завершить, но необходимость произвести обновления обычно отступает перед более срочными или важными задачами. Иными словами, замена платформы, которая обладает сравнительно низкими непосредственными издержками из-за отсрочки, отходит на второй план из-за заданий, отсрочка по которым ведет к более крупным и непосредственным издержкам.

Можно предложить класс обслуживания, который позволит быстро начинать такую работу, или ресурсы, чтобы убедиться, что задание завершено. Но гарантий по времени может и не быть. К тому же это как раз такая работа, которую легко отложить в сторону, если появляются более срочные задачи. Чтобы иметь резервы для обработки ускоренного запроса, должна быть работа с низкой стоимостью отсрочки, которая откладывается в сторону при поступлении ускоренного запроса. И этот резерв как раз обеспечивается элементами нематериального класса.