Одна из популярных тем дискуссий у ИТ-специалистов — это построение «моделей» (patterns) и работа с ними. Под моделями понимаются методы представления данных и манипуляции ими, включая операции изменения, модификации и расширения элементов данных. В сущности, проблема описания имеющейся бизнес-задачи в соответствующих терминах есть проблема поиска подходящей модели или абстракции (pattern matching).

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

Повторим основные понятия

Со временем были разработаны сложные модели, такие как реляционные модели данных, древообразные и сетевые структуры в языке Pascal, правила языка Prolog и объекты с наследованием. Модели можно подбирать, учитывая их вид и форму. Например, можно сравнивать схемы двух сетей с одинаковыми узлами и связями или строки двух реляционных таблиц, проверяя, равны ли значения в столбцах.

Далее возникает вопрос: как нужно дополнить или изменить одну или обе модели, чтобы сильнее сблизить их друг с другом? Вы можете преобразовать модель, созданную в одной форме, в другой вид, и она будет выполнять те же функции, что и исходная (например, можно представить реляционные данные как факты в правилах Prolog).

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

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

Реальные задачи

Многие бизнес-задачи связаны с определением действий во время и после сопоставления двух моделей. Одни модели могут являться подмножеством других или отличаться в заранее заданных пределах. Звучит чересчур абстрактно? Вот несколько примеров.

Рассмотрим основную задачу современных CRM-систем (Customer Relationship Management — управление отношениями с клиентами): продать клиентам как можно больше товаров и услуг, ориентируясь на их потребности. Для этого следует сопоставить модель предлагаемых вами товаров и услуг с моделью потребностей клиента. Общеизвестно, что целевой маркетинг (при условии разумных затрат) более эффективен с точки зрения окупаемости расходов, чем широкая реклама. Интернет и другие компьютерные и коммуникационные технологии позволяют автоматизировать не только весь процесс сопоставления моделей, но и дополнительные действия, косвенно связанные с этим процессом (например, рекомендации по дополнительным услугам и товарам).

Так, информационная система электронного магазина Amazon.com автоматически предлагает покупателю другие книги той же тематики, что и выбранная им, а это обеспечивает Amazon.com конкурентное преимущество перед аналогичными компаниями. В соответствии с канонами рыночной экономики сделка заключается при достижении той цены, по которой покупатель готов купить, а продавец — отдать товар. Amazon.com наглядно демонстрирует, что критично не только нахождение такой цены, но и полная или частичная автоматизация продажи, позволяющая сократить транзакционные издержки. Сопоставление моделей позволяет повысить конкурентоспособность, приближая модель покупательского спроса к модели предлагаемых товаров и услуг или наоборот.

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

Например, причина сообщения о недоступности приложения может заключаться в проблемах с маршрутизацией в сети. В такой ситуации сообщения об ошибке могут поступить и от других точек мониторинга в системе и в сети. Даже при наличии достаточно «интеллектуальных» средств мониторинга сопоставление этих тревожных сигналов, выявление неполадки и автоматическое ее устранение— задача непростая и нетривиальная. На самом деле задача сводится к сопоставлению модели конфигурации исправной системы и модели системы с неполадками и применению некоторого «лечения» для возвращения ее в «здоровое» состояние. Такой подход — на основе сопоставления с моделью — обеспечивает лучшие возможности анализа и разработки схем устранения подобных проблем.

На переднем крае

Сопоставление моделей также используется в процессах проектирования и тестирования информационных систем, в частности, сценарий использования системы (use case) — неотъемлемая часть языка моделирования UML (Universal Modeling Language), поддерживаемого группой OMG (Object Management Group). (Сценарии использования системы можно рассматривать как предопределенную модель взаимодействия пользователей, которой должна соответствовать конкретная реализация системы.) Когда разработка системы завершена, сценарии использования преобразуются в сценарии тестирования, используемые для проверки корректности работы системы. Сопоставление моделей выполняется между сценариями тестирования и фактическим поведением системы. В дальнейшем при проектировании и разработке систем эти сценарии использования можно применять не только для проверки правильности реализации, но и для корректировки готовой системы, «подгонки» ее под сценарий.

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

Но что, если о модели заранее ничего не известно или она еще не оформилась? В этом случае анализ данных (data mining) может помочь найти неожиданные модели с помощью нейронных сетей; кроме того, модели формируются по мере изучения и развития системы. Обе эти технологии представляют ценность и, вероятно, в будущем станут ведущими в этой области.

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

Раджу Кочарекар (Raju Kocharekar) — старший специалист по информатике в отделении корпоративных информационных систем (Corporate Information Systems) группы информационных решений Мирового банка (World Bank's Information Solutions Group). Обладает 20-летним профессиональным опытом в области управления и поддержки ИТ-систем. С ним можно связаться по e-mail: rkocharekar@worldbank.org.