Шрифт:
Я попробую сформулировать, что делалось неправильно и какие решения были найдены, их уже удалось применить большей частью в проектах за пределами Ultima-S на базе ее разработки.
Проектированием системы на самом деле должен заниматься не технарь, а маркетолог как Стив Джобс. Система – это товар, удовлетворяющий потребности. Маркетолог может понять потребности рынка, сформулировать требования к товару, может оценить осуществимость маркетинговой компании. На деле технический архитектор нужен маркетологу для оценки себестоимости проекта и его сроков, а также для информации о новых перспективных технологиях, тогда маркетолог сможет искать сочетания «потребность + технология». Проблема проекта Ultima-S и многих других в том, что там не было маркетолога, определяющего вид продукта и программу продвижения, что сделало бессмысленным большое количество технологических действий.
Следуйте совету Джобса: «Обычные художники заимствуют – великие воруют». Для меня, как руководителя группы разработки бухгалтерского модуля, существовала проблема: никто не мог поставить задачу. Системный архитектор был «не совсем в теме», маркетолог со знанием продукта отсутствовал. Но мне в голову пришла удачная идея начать копировать макроязык и систему настроек 1С, одновременно обеспечивая совместимость с объектной моделью Ultima-S. Если бы разработчики Ultima-S, до того как взяться за написание кода, провели тщательное изучение архитектур аналогов на рынке, все было бы иначе. Можно было бы передовую платформу Ultima-S приспособить к куче хороших идей у 1С и «Галактики». Я в то время часто общался с экспертами «Галактики», они серьёзно опасались, что мы именно так и сделаем: реверс-инжиниринг и переписывание в новой технологии. Ресурсы для этого у нас были. Но, увы, сделали только частично, а 1С – это все-таки модель малого бизнеса, тогда как мы целились в сектор Enterprise, где была «Галактика».
Учитесь у лидеров рынка, их успех не от «просто так». Я получил два важных опыта в этом проекте – объектно-реляционное моделирование и проблемно-ориентированные конструкторы, которые популяризовал Нуралиев. Могу сразу сказать: Нуралиев круче. Дело в том, что его функциональная архитектура была следствием изучения потребности рынка и типовых сценариев внедрения. Наш
бухгалтерский модуль из Ultima-S до сих пор живёт и здравствует в нескольких холдингах, которые не раз оценивали миграцию на Axapta, но оставались все равно на нём. Концепция 1С плюс возможность Transact SQL-программирования – мечта многих разработчиков бизнес-решений. Нуралиева много раз просили это сделать, но он держался за свой подход, чтобы поддержать кросс-платформенность [108] .
Наследование объектов и объект-контейнер с визуальным конструктором. Ultima-S построена на идее наследования классов, как современный вариант PostgreSQL. Если брать модель 1С – это наследование только на системном уровне и отказ от наследования в бизнес-уровне в пользу конструирования путём сложения комбинаций объектов в объект-контейнер с помощью визуальных конструкторов. Модель 1С сильней. Быстрее создаёт новые сущности, за счёт разделения системного уровня и конструктора, она также надёжнее, так как настройщики очумелыми ручками не могут залезть в ядро.
Прикладная разработка не место для эстетического наслаждения от красот технологий. Это бизнес. Ultima-S сильно пострадала от того, что стала чем-то вроде лаборатории Xerox в 1980-х, где масса людей апробировала разные технологии, научилась и пошла делать другие проекты в Apple и Microsoft. Архитектурные эксперименты оправданы, если маркетолог видит преимущества в архитектуре товара, которые преобразуются в удовлетворение потребностей клиентов. Надо оценивать эффективность архитектуры не в терминах красот, а в терминах трудозатрат. Пользователю все равно, он не видит что там внутри. Но он видит, что система дорабатывается медленно или валится с ошибкой. Для меня был огромный плюс, что я познакомился в этом проекте с MS Project и стал в нем анализировать трудозатраты программистов. Выводы были интересные. Я заметил, что программисты и технологии могут выглядеть невзрачно, но давать невероятные эффекты по скорости и надёжности кода в терминах низких трудозатрат, и наоборот, вроде бы красивые решения могут превращаться в «чёрную дыру» для бюджета проекта.
На деле Ultima-S показала, что идея реализации сервера приложений средствами СУБД жизнеспособна и эффективна, также она совместима с лучшими функциональными практиками на рынке, как, например, моделирование в 1С. Но отсутствие маркетолога на проекте в качестве его лидера не дало технологиям добиться коммерческого успеха, который пришёл уже к системам – наследникам Ultima-S.
Во многом разделяя мнение Владимира, хотелось бы добавить, что бороться за статус главного идеолога продукта контрпродуктивно в любой ситуации. Наилучшим, по моему мнению, решением является единство и противоположность технической и функциональных архитектур, развивающиеся при постоянном диалоге групп, ответственных за техническую реализацию решения и функционал продукта. Такая практика используется в рамках MSF, в том числе и в самой Microsoft.
Считать трудозатраты на разработку архитектуры и ядра достаточно сложно. Ещё труднее считать отдачу в дальней или даже средней перспективе. Если при разработке заказного проекта в первой версии приоритетом может быть именно ближняя перспектива, то в продуктовой разработке такой подход неизменно приводит к необходимости полной переделки второй версии.
С прикладной разработкой всё относительно просто: есть функционал, оцениваемый заказчиком или маркетологами в конкретную сумму, есть трудозатраты на его реализацию, остальное – прибыль от деятельности. Чтобы убедиться, насколько хороши техническая архитектура и платформа, как они влияют на производительность прикладного программирования в растущем проекте, надо более формально разделить эти два направления деятельности, чего сделано не было.
В конце концов, на любом серьёзном производстве кроме непосредственно цехов и мастерских есть лаборатории и конструкторские отделы, работающие на перспективу, а степень наукоёмкости или, как ещё говорят, высокотехноло-гичности продукции, напрямую зависит от доли вложений в перспективные разработки, заключённой в себестоимости товара.
Критическая масса клиентуры в проекте, выводящая его на прибыльность, не была достигнута, что послужило формальной причиной закрытия после более чем трёх лет существования. Но история на этом не кончилась.
Не прекращалась поддержка некоторых клиентов. После перерыва базовая часть системы была переименована в NEXUS и перешла в домен разработок с открытым кодом. Оказалось, что платформа является весьма эффективным средством автоматизации небольшими группами и индивидуальными консультантами с хорошим знанием технологий. Было проведено несколько новых внедрений системы на базе только самой платформы с полной разработкой прикладного кода.
Возвращаю слово Игорю Паньшину, чей рассказ в предыдущей главе был коротким.
Я хотел бы рассказать о внедрении, на которое у меня ушло несколько лет. Думаю, всем известно, что такое оператор сотовой связи. Но мало кому известно, что такое сотовый оператор, у которого завтра отберут частоты. Таким оператором оказалась Петросвязь или РТК (Радио-Телекоммуникационная Компания), имевшая оборудование QUALCOM на частотах 800 МГц, которые решили отдать телевидению. Первыми сбежали разработчики биллинга BillOnLine, оставив работающую систему без всякой поддержки. На свою беду, как я не мог бросить тогда VАХ, так не смог уйти от умирающей в прямом смысле слова системы.
Выход был найден. Бралось ядро NEXUS и компилировалось в работающую базу системы BillOnLine. Тонкий клиент сразу начинал работать. Оставалось дописать классы, которые поддержали бы бизнес-задачи предприятия, что и было сделано. Подход имел ещё одно интересное преимущество перед всеми мне известными. Скрипт ядра позволял устанавливать его в базу данных практически всех систем MSProject, DOCSVision, 1C 7.7 и 1С 8, что сразу давало дополнительную свободу управления и способность дорабатывать штатную систему под нештатные нужды организации без привлечения разработчиков продукта. Основным преимуществом является способность решить бизнес задачи в рамках SQL-запросов и хранимых процедур на порядок или два быстрее, чем любая программная платформа.
Правда, сейчас, после 10 лет разработки и внедрения Ultima-S называется NEXUS, но это сути не меняет. В настоящий момент я работаю на перекрёстке NEXUS и 1С 8, обеспечивая нужную производительность учётной системы в целом. Это даже не разработка, а сопровождение-разработка.
Другой ключевой особенностью платформы является возможность анализа хозяйственной деятельности предприятия практически в реальном времени. Как только документ оперативного контура меняет состояние «черновика» на одно из действительных, информация отражается на счетах управленческого учёта с заданными разрезами. Об этом подробнее рассказывает Сергей Быков, ведущий специалист BI.
Технические ограничения эпохи бумаги и слабых ЭВМ вынудили «зашивать» аналитику в код счета. До сих пор многие системы, спроектированные профессиональными бухгалтерами, реализуют именно этот подход, например Oracle и SAP. Получить подробные данные о деятельности предприятия из классической главной книги (ГК) невозможно: количество сегментов в коде счета ограничено очень скромным числом (4–8).
Из-за этого возникла задача анализа хозяйственной деятельности предприятия. Но по сути эта всё та же учётная задача – построение отчётов об операциях на основании заданных правил группировки типов документов. Такая группировка делается и в ГК, но с потерей существенной для принятия решений информации.
Бухгалтерский движок в NEXUS позволяет преодолеть «проклятие» учёта по плану счетов с сегментацией кода счёта. Код отражает только вид операций – кассовые, банковские, складские, производственные и т. д. Существенные признаки операций сохраняются в виде аналитических срезов. В результате получается структура, сразу пригодная для OLAP [109] .
Судите сами, Saldo – таблица фактов, несколько раз соединённая с таблицей Docs (измерения). Классическая «звезда». Для того чтобы помочь OLAP-клиенту, создаём отдельные view для каждой роли таблицы Docs – клиенты, товары, счета (в понятии регистров учёта), валюты, партии и т. д.
Далее подключаем эту структуру в Excel и получаем готовый OLAP, который наполняется данными в соответствии с учётной политикой предприятия, непосредственно в момент выполнения хозяйственных операций. Это не просто анализ операционной деятельности, это сверхоперативный анализ! Такая оперативность в других, более раскрученных системах возможна только в виде ограниченных плоских отчётов, построенных по первичным документам.
Я поддерживаю системы на этом «моторе» уже 10 лет – решение на удивление простое, гибкое и мощное. За это же время имел опыт использования JDEdwards OneWorld, Oracle Apps и в меньшей степени с SAP.
История системы продолжается.
Нешаблонное мышление
Моя профессиональная практика складывалась таким образом, что обсуждение обобщённых решений касалось прежде всего задач предметной области и соответствующего уровня абстракций. С некоторой натяжкой их можно отнести к аналитическим шаблонам, так как в качестве основы брались только существенные части структур, интерфейсов или даже просто рабочие идеи. Лучше назвать их аналитическими эскизами.
О типовых решениях уровня реализации речь заходила редко, но уже в середине 1990-х годов иногда возникали упоминания книги GoF – «банды четырёх» [110] [6] о приёмах объектно-ориентированного проектирования, где была предпринята попытка их обобщения. Признаюсь, руки долго не доходили до непосредственного ознакомления с этим трудом, но где-то в начале годов 2000-х издание наконец попало ко мне в руки.
Имея уже немалый опыт проектировщика и программиста, я надеялся найти в книге, как минимум, более проработанный вариант приёмов, использованных в предшествующих проектах. Достаточно быстро я обнаружил, что за многолетнюю практику большинство описанных авторами шаблонов было совершенно невостребованным кругом решаемых задач. Те же оставшиеся, что удалось идентифицировать, несколько удивили простотой и не всегда отражающими суть названиями.
Полагаю, что для человека, знакомого с основами ООП, вынести зависящую от контекста операции логику в специализированные обработчики или даже в классы, имеющие единый интерфейс вызова, является несложной операцией, над которой придётся раздумывать несколько минут. Например, часто такая задачка возникает в разного рода генераторах, когда по исходной модели нужно выдать код на том или ином языке программирования. Видимо поэтому, мне и не приходило в голову величать такую операцию «стратегией». Не ассоциировалась у меня тактическая перестановка фигур на шахматной доске со столь солидным термином.