Евгений Захарович Зиндер — директор аналитического и конструкторского бюро «Группа 24», руководитель проектов, в которых была использована как архитектура К-С, так и другие подходы. Он курирует рубрику «Директору», ему можно написать по адресу ezinder@osp.ru

  
Есть такой лозунг: «Думать вредно!». Конечно, те, кто его продвигает, не имеют в виду, что их слушатели (нередко — это их возможные заказчики) должны вообще перестать пользоваться корой своего головного мозга. Чаще всего подразумевается, что им надо выбирать для своей ИС решение (архитектурное, программное или иное), которое стало типовым и распространенным, и что именно такое решение и предлагается поставить заказчику. Еще более обоснованным выглядит этот лозунг в случаях, когда за типовым решением стоит промышленный, а то и международный стандарт.

Интересно, что в некоторых «продвинутых» методиках совсем не так давно появились специальные разделы, помогающие убеждать заказчика отказаться от мэйнфрейма и перейти на платформу клиент-сервер (далее «К-С»). Тем временем прогресс не стоял на месте. Появились многозвенные архитектуры, СУБД стали предоставлять возможности поддержки распределения данных все большим числом способов.

И вот вдруг Ларри Эллисон заявляет, что К-С — это грандиозная ошибка! Появилась и масса менее громких сообщений, например, о преимуществах Web-инструментов управления проектами по сравнению с продуктами именно архитектуры К-С (см. статью Кэтлин Мэламьюки).

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

Что же на самом деле?

Обратим внимание на то, что по сути Эллисон сказал не о вреде разнесчастной пары К-С, а о вреде плохого проектирования информационной архитектуры в своей корпорации. Ведь К-С не заставляет распределять базу данных по 70 узлам.

Полезно подумать и о других условиях внедрения ИС. Например, вряд ли оправданно не использовать прием распределения данных по разным серверам в условиях плохих каналов связи (говоря о распределении данных, я вовсе не имею в виду технику тиражирования, поставляемую какой-то конкретной фирмой).

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

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

Что это означает

Это означает не только то, что архитектура К-С остается, так же как остается и централизованное ведение интегрированных баз данных и их распределение, если оно диктуется требованиями ситуации в проекте.

Все это означает, что думать все-таки необходимо. И если вам предлагают решение, основанное на стандарте, изучите этот стандарт, определите степень его гибкости, представьте последствия его применения. Даже стандарт на документирование ПО может принести большой вред — при неправильной его трактовке, адаптации и применении.

Ну а лозунг «Думать вредно» — что о нем сказать?

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

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

Другая заключается в печально известной изменчивости нормативной базы ИС наших предприятий на всех уровнях — от государственных требований до организационных структур внутри предприятия.

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

А еще есть статистика, говорящая о том, что в Штатах меньшая часть предприятий, делая ERP-системы, использует интегрированные ERP-пакеты. Ведь есть и другие подходы. Но это снова означает, что надо думать...