|
Интересно, что в некоторых «продвинутых» методиках совсем не так давно появились специальные разделы, помогающие убеждать заказчика отказаться от мэйнфрейма и перейти на платформу клиент-сервер (далее «К-С»). Тем временем прогресс не стоял на месте. Появились многозвенные архитектуры, СУБД стали предоставлять возможности поддержки распределения данных все большим числом способов.
И вот вдруг Ларри Эллисон заявляет, что К-С — это грандиозная ошибка! Появилась и масса менее громких сообщений, например, о преимуществах Web-инструментов управления проектами по сравнению с продуктами именно архитектуры К-С (см. статью Кэтлин Мэламьюки).
Самый примитивный вывод мог бы состоять в том, что так же, как несколько лет назад пошел «накат» систем К-С, теперь идет массированный прессинг в пользу покупки очередных новых товаров. В частности, систем с хост-машиной и HTML-интерфейсом. А потому «думай не думай — все едино», ведь производители меняют время от времени расцветки и архитектуры, предугадать их поведение трудно, а брать-то приходится то, что дают.
Что же на самом деле?
Обратим внимание на то, что по сути Эллисон сказал не о вреде разнесчастной пары К-С, а о вреде плохого проектирования информационной архитектуры в своей корпорации. Ведь К-С не заставляет распределять базу данных по 70 узлам.
Полезно подумать и о других условиях внедрения ИС. Например, вряд ли оправданно не использовать прием распределения данных по разным серверам в условиях плохих каналов связи (говоря о распределении данных, я вовсе не имею в виду технику тиражирования, поставляемую какой-то конкретной фирмой).
Конечно, у Эллисона (и не только у него) есть и другой мотив: клиент противопоставляется не примитивному терминалу, а Web-интерфейсу, который прост в применении и дешев в сопровождении. Но давайте посмотрим: вряд ли разговор должен идти о том, что на рабочих местах должны остаться только браузеры. Ограниченность Web-интерфейсов уже неоднократно обсуждалась, и это не стоит разбирать подробно (можно сослаться на статьи, ранее опубликованные в нашей рубрике).
Кроме того, К-С — это не фирменное решение. Это идейный подход, предполагающий целый набор способов распределения нагрузки между техникой на рабочем месте и средствами основной вычислительной машины (машин). Гамма этих способов широка, и в каждом частном случае хорошо будет работать тот из них, который наиболее рационален именно в этом случае. Иногда важнее сокращать затраты на сопровождение, в других случаях критичной может быть скорость работы на рабочем месте.
Что это означает
Это означает не только то, что архитектура К-С остается, так же как остается и централизованное ведение интегрированных баз данных и их распределение, если оно диктуется требованиями ситуации в проекте.
Все это означает, что думать все-таки необходимо. И если вам предлагают решение, основанное на стандарте, изучите этот стандарт, определите степень его гибкости, представьте последствия его применения. Даже стандарт на документирование ПО может принести большой вред — при неправильной его трактовке, адаптации и применении.
Ну а лозунг «Думать вредно» — что о нем сказать?
Последний раз я слышал эту фразу в связи с так называемыми «корпоративными» ИС. Имелось в виду, что не надо разрабатывать свои прикладные системы масштаба предприятия, поскольку есть готовые ERP-пакеты. Такие пакеты реализуют архитектуру ERP-систем, а эта архитектура опирается на тот функциональный состав, который уже определен как своего рода стандарт.
Все бы хорошо, да только есть проблемы, и вы их знаете. Одна состоит в том, что разрыв между подходящими предприятию функциями пакета и реальными нуждами в нашей практике много больше, чем в западной (там успехом считается, если этот разрыв не превышает 30%).
Другая заключается в печально известной изменчивости нормативной базы ИС наших предприятий на всех уровнях — от государственных требований до организационных структур внутри предприятия.
Есть еще одно обстоятельство, состоящее в том, что окостенелые оргструктуры не принимают радикальных изменений, требуемых для новых ERP-процессов, ну а в таком случае думать приходится еще больше.
А еще есть статистика, говорящая о том, что в Штатах меньшая часть предприятий, делая ERP-системы, использует интегрированные ERP-пакеты. Ведь есть и другие подходы. Но это снова означает, что надо думать...