Различия кастомизируемых программных продуктов и заказной разработки

Продолжаю развивать тему перехода от заказной разработки к продуктовым решениям. Сразу оговорюсь, что речь, конечно, идет не о программах, тиражируемых в сотнях тысяч или миллионах экземпляров, а об информационных системах, внедряемых в нескольких десятках, может быть сотнях организаций. Как я уже отметил в предыдущем сообщении, такие системы от заказных решений отличает наличие архитектуры и процесса внесения изменений. Philippe Kruchten с соавторами в статье Ретроспектива программных архитектур явно отмечает, что архитектура «отражает замысел разработчиков, связанный со структурой и поведением системы, и защищает ее от «эрозии» под воздействием работ по сопровождению.» Об этом же говорит Yefim Natis (Gartner) в работе Conquering IT Complexity Through Software Architecture ( В переводе на русский Покорение сложности ИТ): «Неконтролируемая сложность дорого обходится и сильно мешает, плохо сказываясь на способности к адаптации и изменениям. Однако сложность — вовсе не результат ошибок, а прямой результат адаптации и изменений, свойство растущей компьютерной среды. Это цена, которую пользователи платят за инновации.» Но далее, в той же статье Натис пишет, что избавится от потока изменений программных систем нельзя, а Эрик Реймонд в работе Волшебный котел красноречиво убеждает нас в том, что сопровождение является основной деятельностью программиста « любой разработчик программного обеспечения или специалист по системному анализу скажет вам, что оно (сопровождение) составляет большую часть (более 75%) оплаченной работы, которой занимаются программисты.»

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

Приведу конкретный пример – движок этого блога wordpress. База данных текущей версии wordpress состоит из десятка таблиц (11, если я не ошибаюсь): сообщения, комментарии, пользователи, таксономии, связи, плюс метаданные по этим объектам. Отрисовка пользовательского интерфейса вынесена в темы. Дополнительный функционал в плагины. Команда разработки развивает движок и приложения для мобильных устройств (кстати, посмотрите на свой блог в iOS и в android – будете приятно удивлены), а полторы тысячи тем, 16 тысяч плагинов и локализация продукта – результат работы сообщества. Задумайтесь, база данных одной из ведущих CMS состоит из десятка таблиц, а самая большая таблица – 23 поля. Разработчикам корпоративных информационных систем есть к чему стремиться.

Различия кастомизируемых программных продуктов и заказной разработки: 8 комментариев

  1. Спасибо за пост! Тема и вправду очень интересная. Мне кажется, что сложность растет по причине универсальности продаваемых систем. Например, система собственной разработки для учета проектов, которую мы сделали в 2002 году, верой и правдой прослужила несколько лет – все было просто и понятно. Сейчас заменили на коробочную – сложность системы на два порядка выше, чем была, при подобном фукнционале 🙁

    1. Спасибо за комментарий и пример! Я бы не стал ставить знак равенства между универсальностью и сложностью, думаю здесь скорее желание запихнуть в систему побольше функционала. А что касается примера, так это вообще очень типичный кейс, подтверждающий тот факт, что программисты пишут хорошо те системы, которые делают для себя и бесплатно и плохо те – которые для других и за деньги.

      Я надеюсь что “продуктизация” хороших систем – это один из способов сократить покупки сложных и дорогих коробок

  2. Увы, “концепция микроядра с подключаемыми модулями” вовсе не единственный, и даже не всегда желательный способ “ограничивать глубину изменений”. Это довольно узкоспециальный “технократический” прием, не работающий в массе случаев, зря вы к нему всё сводите.

    Как раз недавно я об почти об этом же писал (http://ilobanov.wordpress.com/2011/09/14/approaching-lean-engineering/). Вкратце, всё именно так, как Вы пишете в первом абзаце. С глубиной изменений (то есть с лишней работой) предлагается бороться двумя способами: выбором архитектурного стиля, хорошо разделяющего изменчивые и постоянные части системы, и выбором подходящего процесса разработки. Микроядро это годный стиль, но, ограничивающий гибкость (точки расширения только там, где предусмотрены) и бесполезный сам по себе, когда продукт является платформой, как в случае с ERP-пакетами.

  3. Максим, на мой взгляд пост спорный.

    Начну с заголовка: custom software на русский переводится как “заказное ПО”. Т.е. разницы между кастомизируемым ПО и заказной разработкой нет. Так что лучше “кастомизируемых” из заголовка убрать, дабы оставить лишь саму суть: отличие продукта на заказного ПО.

    Во вторых, и уже по сути поста – просто убила фраза:
    >Как я уже отметил в предыдущем сообщении, такие системы от заказных решений
    >отличает наличие архитектуры и процесса внесения изменений
    Т.е. в заказных решениях нет архитектуры? Она (архитектура) может быть не масштабируема, не гибка, не “абстраткно” красива в конце концов, но говорить об ее отсутствии это уж слишком.

    Третий момент по поводу движка wordpress. Причиной создания механизма плагинов была отнюдь не технологическая подоплека такого решения, а попытка (успешная) привнесения user generated content парадигмы в область функционала. Очевидно, что команда wordpress не может закрыть все потребности, ну так пусть пользователи сделают это сами! 90% маркетинга и 10% технологичности, хотя не спорю, технологические плюсы такого решения есть.

    И самое главное – вопрос отличия продукта от заказного ПО вполне адекватно описан
    – у Брукса в первой же главе мифического человеко-месяца.
    – у Спольски в пяти мирах (как разница между одноразовым ПО и тиражкой).

    Сводить все к наличию в продукте архитектуры и поставленного процесса change management – имхо не корректно.

    В завершении – прошу не рассматривать пост как “наезд”, тема действительно интересна, но мне показалось изложение однобоким и местами я явно не согласен с автором.

    1. Андрей, спасибо за комментарий.

      Пост, возможно, и выглядит несколько провокационным. Но разве я виноват в том, что разработчики заказных систем не уделяют внимания архитектуре своих решений. Безусловно, не все системы представляют из себя один java архив, но можно ли наличие в системе нескольких модулей назвать архитектурой? Может мне просто не повезло, но не вижу я заказных систем(практически не вижу), которые могли бы быть повторно используемы. Кстати, насколько я помню, у Брукса говорилось о том, что продукт из программы делает именно абстрагирование. Абстрагирование входных данных, позволяющих использовать программу для решения более широкого круга задач.

      Еще раз повторюсь, что речь идет о моем личном опыте. С удовольствием его скорректирую, увидев программы содержащие внутри себя что-либо осмысленное

    2. По поводу названий. В англоязычных текстах принято использовать термины software package или software suite в качестве противопоставления custom software. Наверное на русский, действительно, лучше переводить как программный продукт и заказное ПО

  4. Максим,

    Я соглашусь с вами в оценках качества проектов по заказной разработке (из тех, что я видел в России). Да, архитектура отсутствует или ужасна, тоже самое можно сказать про код, документацию, сопровождение. Но мне кажется мы с вами расходимся в point of view на эту проблему и в оценке причин этого явления.

    Я вижу причины не только в технологических составляющих но и в бизнес компоненте процесса:

    1. 90% гостендеров и значительный процент конкурсов коммерческих структур устанавливают не реальные сроки исполнения работ. Думаю про 16-30 дней на создание прототипа национальной ОС вы слышали.
    Естественно срыв сроков даже при работе с адекватным заказчиком приводит к финансовым проблемам исполнителя, ибо юристы заказчика часто прописывают штрафы на срыв сроков.

    Как итог исполнитель либо проектирует дней за 5, либо просто “пропускает” этап проектирования, красиво называя это agile разработкой. Проектировать ему конечно все равно придется, но делается это урывками, вне контекста всей ит инфраструктуры и ит ландшафта, что называется “на коленке”.

    2. Подавляющее большинство коммерческих структур не согласны оплатить 2-4 недельный предпроект на этапе которого потенциальный исполнитель может провести предварительное обследование, собрать требования и на их основе предложить грамотную архитектуру.

    3. По поводу абстрагирования, например, для повторного использования у другого заказчика.

    В телекоме различия между бизнес процессами, например у операторов большой тройки, еще не фатальны, но вот в других отраслях не осчастливленных стандартами (привет eTOM!) эти различия громадны. Отчасти поэтому с технологической точки зрения большинство заказных систем являются одноразовыми, ибо шансы перенести их даже на второго заказчика минимальны. Так стоит ли городить огород с абстрагированием, интерфейсами и прочим когда можно “прибить гвоздями” и сделать быстрее?

    4. Грамотное проектирование архитектуры требуется квалифицированных кадров со стороны исполнителя (в первую очередь архитекторов\ГИПов). Такие кадры есть, но их катастрофически не хватает и часто используются такие профессионалы не для проектирования системы в начале проекта а для тюнинга и вытаскивания уже проваленных проектов в их конце когда не проходятся нагрузочные\стресс и прочие тесты.

    Т.е. для меня виновны в подобной ситуации как заказчики так и исполнители (примерно поровну), причем не только технари но и закупки от заказчика и продавцы от исполнителя.

    И второй момент – в посте вы описали проблему, но не раскрыли подробно варианты ее решения. Понимаю что серебряной пули нет, но было бы очень интересно если бы вы поделились опытом\соображениями по данному поводу.

    У меня, к сожалению, положительный опыт решения данной проблемы был только на проектах за пределами РФ либо для зарубежных заказчиков, в РФ это скорее исключение 🙁

    1. Я согласен с тем, что качество решений категория скорее “экономическая”, чем технологическая. И заказчики не меньше ответственны за качество ПО, чем исполнители…, даже больше, так как именно они формулируют требования. То что заказчики(специалисты по закупкам, владельцы бюджета, руководители компаний) не разбираются в информационных технологиях их мало извиняет.

      Я не думаю, что тенденция к снижению качества корпоративного ПО изменится. А вот про варианты решения я как раз и стараюсь писать в этом блоге. Если говорить совсем кратко, то основная идея в том, чтоб не развивать все системы сразу, ограничить глубину изменений, вкладываться только в несколько систем в организации, но развивать их последовательно и аккуратно.
      Это, в определенном смысле и есть идея BPMS/SOA и идея MDM систем

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

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