Исключая мелкие текущие модификации примерно так.
1) Единый модуль трафика. IPv6, ISG (и Juniper ERX), DHCP.82 + динамика и т.п. Резервирование шлюзов авторизации (RADIUS).
2) Единый модуль голоса. Возможность переобработки логов как RADIUS так и CDR.
3) Перевод основных таблиц на транзакционный режим. InnoDB как дефолтовый движок для таблиц, MyIsam как исключение для различных логов.
Ещё изучается вопрос миграции на Postgre, но пока тесты не особо впечатлили. В 9.0 хоть появилась быстрая штатная реплика, посмотрим дальше, сейчас вон оракл MySQL что-то улучшил
Транзакционный режим работы акшенов сервера, для целостности БД в случае сбоя по середине акшена.
Для этого нужно переделать всё API на выброс исключений наружу.
4) Движок кэша. Есть задумка кэшировать все договора, их параметры и учётные данные (логины/пароли) в памяти для более быстрого получения при необходимости.
Возможно потребуется делать распределённый кэш. К общему кэшу смогут обратиться все приложения биллинга по JMS.
И ещё возможно специализированные кэши с учётными данными на серверах авторизации, можно было бы быстро делать проверку логинов-паролей а потом
запрашивать центральный кэш для предоставления договора, его тарифов и т.п.
5) Распределение БД. Собственно учётные данные будут лежать в единой транзакционной БД + кэш обеспечивающий быстрый доступ к ним.
Различные логи, балансы, сессии - разнесены по разным БД. Но тут нужно подумать. Возможно, проще сделать различные таблицы либо партиции таблиц в единой БД,
разделив по договорам. Возможно проще вообще сделать несколько экземпляров модулей и реализовать текущими средствами.
При разделении БД возникают проблемы с отчётами, с джойнами.

Блуждающие мысли:
1) Отвязка учётного периода от месяца. Для физ. лиц, возможность делать их плавающими с привязкой всего к нему абонплат, списаний, услуг и т.п.

P.S. Если есть ещё вопросы по роадмапу - поднимите отдельную тему, чтобы путанницы не было. А оттуда делать ссылки на темы с конкретными обсуждениями что ли.. А ту главную можно прилепить.

тоесть BGCRM будет заниматься учетом а сам биллинг калькулировать?

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

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

Но есть так же много сущностей которые и там и там. Например коммутаторы. Традиционно, учет оборудования относится к задачам так называемого Inventory. Таким образом BGCRM, замахивается быть ещё и Inventory. А нам например, коммутаторы нужны в биллинге, а заявки нет.. Хотелось бы отделить.

И ещё хотелось бы иметь возможность видеть лог действий пользователей. Кто, что, когда правил, чтобы можно было разбор полётов устраивать.

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

Идельно, если бы можно было бы отвязать понятие учётного периода от месяца и иметь гибкий механизм. Например:
1. Учётный период - календарный месяц
2. Учётный период по желанию - 30 дней или сколько надо с момента активации услуги, т.е. абонплата 1000р - заплатил 1000 р проработал учётный период, неважно с какого числа, кончились - заблокировался, опять заплатил 1000 - ещё один учётный период отработал
3. Учётный период по желанию - 30 дней или сколько надо, который идёт один за другим, как бы месяц
4. ???

А разве сейчас понятие учетный период привязан к месяцу?

вот как раз только он и не привязан, а тот же npay (как узел тарифа) привязан и поэтому начислять приходится в рамках одного календарного месяца

Добавили в 5.2 версии возможность написания обработчиков скриптов и логики управления шлюзами Inet просто на Java.
Меню "Сервис - Автоматизация - Управление динамическим кодом".
Всю логику Inet модуля перевели на чистые Java классы взамен BeanShell.
Преимущества:
1) Возможность разработки в полноценной сторонней IDE, прелинковав каталог BGBillingServer/dyn как исходники. Автокомплит, проверка синтаксиса.
2) Скорость до 50 раз быстрее BeanShell (BGBS).
3) Больше возможностей языка (параметризация, переменное число аргументов в методах).
4) Возможность валидации классов при компиляции на соответствие API.
Скомпилированные классы помещаются в БД, откуда могут быть загружены всеми приложениями.

Я так понял что только для этого модуля? а все остальное так же и останется на скриптах?
http://bgbilling.ru/v5.2/doc/ch02.html

Нет, везде где было возможно выполнить скрипты появилась возможность выполнять Java-код в качестве альтернативы (это и событийные, и глобальные скрипты).

А Java-код на события повешать можно будет?

А я что только что сказал?