Рубрика: Software architecture

В заметке Software product management я обозначил целесообразность перехода от заказной разработки ПО к разработке программных продуктов. В сообщении Различия кастомизируемых программных продуктов и заказной разработки высказал свои соображения о необходимости выделения повторно используемых компонент, но не дал каких-либо конкретных рекомендаций как это сделать. Вообще говоря, разработчиков ПО никто не учит выделению повторно-используемых компонент. Объектно-ориентированный подход здесь не очень хорошо подходит. Нас учили выделять повторно используемый функционал в библиотеки классов и наследовать этот функционал при разработке решений. Но библиотеку классов продать довольно проблематично. Да и кастомизация программного продукта, таким способом доступна только более-менее подготовленному программисту. Одним словом, нам нужно научиться выделять готовые повторно-используемые настраиваемые компоненты, которые можно показать заказчику.

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

1. Делим все данные на транзакционные данные и справочники. Справочники выносим в отдельный компонент. База данных у транзакционных записей и справочников может быть общей, но пользовательские приложения для управления справочниками, модули, реализующие SOAP или REST интерфейс и т.д. надо выделять. Рассказываем интересную историю о том, что в нашей системе есть модуль управления справочниками (если позволяет наглость, то можно использовать термин управление основными данными). Данный модуль позволяет хранить информацию о пользователях, ролях, бизнес-процессах, основных активах и т.д. Демонстрируем красивое web-приложение, напоминающее explorer или консоль сервера приложений с иерархическим справочником объектов в левой части окна и формами для их просмотра в правой. Не забываем упомянуть о том, что нам хорошо знакома задача синхронизации справочников в разрозненных информационных системах заказчика и потому наш справочный модуль предоставляет программный интерфейс, позволяющий другим приложениям использовать наши справочники. Безусловно, наши справочники самые лучшие, так как хранение истории изменений позволяет застраховаться от ошибок оператора, а управляемые пользователем гибкие классификаторы от ошибок архитектора данных

2. Транзакционные данные очевидным образом выносим в другие модули. Здесь возможно несколько вариантов. Исторические данные по транзакциям можно просто хранить, выдавать по запросу оператора (т.е. искать транзакцию по ряду параметров), агрегировать в отчетность, использовать в качестве источника для BI системы. Все это разные варианты использования а, следовательно, и разные модули. Выдача информации по запросу реализует вариант использования — решение инцидентов (в широком понимании), а отчетность необходима для управления. Есть еще функция мониторинга, управления проблемами, контроля соблюдения SLA и еще много-много функций, требующих транзакционных данных. По таким данным, вы в онлайне можете отслеживать соблюдение планов и если, например, к 11 часам утра общая сумма выручки по сегодняшним транзакциям меньше ста тысяч рублей, то бежать делать втык сотрудникам. Но этот вариант использования уже для истинных гурманов научного менеджмента.

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

4. Аналогичный подход уместен для управления изменениями. Подробнее см. сообщение Кнопка «Feedback» в бизнес-приложениях Не отдавайте работы по сопровождению продукта айтишникам заказчика. До вас не дойдет и десятой доли новых требований. Замкните её на себя и используйте для придумывания функционала будущих версий.

5. Социализация и мобилизация – две современных идеи, которые просто недопустимо оставить без внимания. С мобилизацией все довольно просто. У вашего приложения должен быть клиент для iOS и android, а внутри системы – шлюз, обеспечивающий безопасный доступ этим приложениям через сеть Интернет (он же пригодится вам для реализации двух предыдущих пунктов). С социализацией немного сложнее. Корпоративный tibbr ваш заказчик, скорее всего, еще не купил (см. Интранет, интеграционная среда или корпоративный портал?), так что взаимодействие пользователей придется налаживать вам. Впрочем, это отличная новость. Вам решать, в каких формах ваши пользователи могут добавлять комментарии, как построить уведомление об этом других участников процесса посредством e-mail или SMS, как управлять группами доступа (если пользоваться социальным сленгом: кругами, друзьями, одноклассниками), какие события выносить в новостные ленты и т.д. и т.п.

Надеюсь, мне удалось показать, что тема перехода от заказной разработки к производству программных продуктов – это не только маркетинг. Об этой составляющей «продуктизации» разработки довольно много информации можно почерпнуть в Блоге российского сообщества менеджеров программных продуктов Но основное место в разработке продукта должен занимать сам продукт, не так ли?