Статья: Новая платформа = новая методология?

[Статья]

<p>
Ну вот, нам представили уже почти окончательную версию V8. Презентация
дала ответы на многие технические вопросы, но породила ряд других
вопросов, уже <i>концептуальных</i>. </p>
<p>
Речь уже не о самой платформе, а о модели разработки конфигураций под неё
(в первую очередь*– типовых и отраслевых). Останется ли модель
прежней, как у V7, или будет изменена? Ведь сама платформа изменилась очень сильно.


<p>&nbsp;</p><p>Первая мысль такая: V8 будут продвигать и продавать не на уровне главного бухгалтера,
а повыше. Главной мишенью, по логике вещей, станут топ-менеджеры, <i>управленцы</i>.
Главный бухгалтер тоже может попасть в их число, но уже в контексте не фискального
учёта, но <i>финансового</i>.
<p>
Также очевидно, что первые продажи V8 будут прямо лоббироваться IT-менеджерами тех
компаний, где уже используется V7, используется на пределе и её возможностней не хватает.
Ну, как это было с первыми продажами "клиент-серверной" версии 7.5.
<p>
Главный вопрос: потребности такого рынка. <i>Какая</i> система им нужна? Будут ли
они пользоваться типовыми, какими именно и <i>как</i> именно. Имеет ли смысл
разработка "комплексной" конфигурации под V8 и будет ли нужна такая конфигурация
хоть кому-то?
<p>
Если пораскинуть мозгами, то вырисовывается следующая схема.
<ul>
<li>Система состоит из модулей.</li>
<li>Модули суть кирпичи, из которых собрано здание. Стыкуй, как хочешь.</li>
<li>Не последнюю роль в разбиении системы на модули будет играть
реальная финансовая структура предприятия.</li>
<li>Собирая систему, нужно идти от <i>целей</i>, строить нужно не под какую-то абстрактную
типовую методику, а под конкретную <i>схему работы компании</i>.</li>
</ul>
Связи между отдельными модулями должбы быть слабыми и настраиваемыми. Организовать это
можно по-разному, скажем, отдельные конфигурации обмениваются между собой данными
(через XML или ещё как-то). Или же система реализована в виде одной конфигурации, части
которой могут работать отдельно друг от друга. Правила связывания, разумеется, настраиваются.
<p>
В чем премущество такой схемы? Обычно при сложном внедрении систему запускают в несколько
этапов, заменяя блоками новой системы блоки старой. Физически невозможно запустить всё
и сразу. Описанная технологическая схема идеально укладывается в концепуию "блочного" строительства информационного пространства предприятия.
<p>
Каждый модуль может быть обновлён отдельно от всех остальных. Потребность в обновлении
у разных модулей разная (а также у разных модулей разная специфика, разные разработчики
и т.д.)
<p>
Так же интересна идея организации обмена данными (УРБД или любой другой механизм обмена)
в контексте отдельных модулей, а не системы в целом. Пример*– распределённые склады (т.е.

Читать всю статью: http://www.klerk.ru/soft/1c?2347

[Fosihas]

Глупо ругать язык программирования, тем более на стадии разработки.