Комментарии 10
Почему именно сервисы?
Почему именно разработка ERP с нуля?
Вкручивать туда решения SAP — дорого. 1С — сложно интегрировать с остальными сервисами. Любая рассматриваемая коробка могла бы подойти, но имела кучу минусов. У нас возникали идеи использовать коллаборацию коробок (использовать готовые SRM и CRM системы), использовать их API и создавать сервисы вокруг. Но клиент решил, что он предпочтет переплатить за гибкий подход к его процессам и строить систему, которая не будет завязана на архитектуру коробки. На мой взгляд, это правильное решение в перспективе 3-4 лет.
Планы по развитию этой системы долгоиграющие. Планируется десятки интеграций в крупную экосистему головной компании. Подход сервисной архитектуры окажется проще и надежнее, когда это время придет.
Если ТЗ создавали специалисты заказчика — я думаю, через пару лет клиент столкнется с результатами ошибок при постановке задач.
Например, финансы (это моя специализация). Я не знаю ни одного финансиста, кто мог бы выдать достаточно корректное ТЗ, которое не аукнется через пару лет. В большинстве коробок, у которок есть сотни — тысячи внедрений, эти косяки уже обнаружены и косяки устранены или найдены обходные пути. Но пользователи и понятия не имеют о большинстве потенциальных сложностей, и, соответственно, не могут о них рассказать.
После передаем требования проектировщикам на разработку интерфейсов и дизайн. В нашем случае, дизайн опущен, т.к. в ERP системах это не критично и мы в целом выдерживаем только определенные правила цветовой схемы и брендинга клиента.
ТЗ уже валидируется вместе с архитектором и тимлидами.
Обычно это занимает довольно много времени, проходит несколько этапов.
Как раз таки благодаря отсутствию больших коробок, мы можем прорабатывать объектную модель так, как считаем нужным. Мы не завязаны на кору, т.к. кор мы пишем сами. Как и говорил, это дольше и дороже, зато процессы выстроить проще и система строится именно под клиента.
Фин.система сейчас в процессе выстраивания. Вся идея сводится к тому, чтобы не подстраивать сервисы под финансовую модель, а агрегировать всю логику работы с финансами в рамках одного (пока что) сервиса. Пока на полную мощность эта интеграция не вышла, но ее архитектура позволит двигать ее куда будет нужно без аффекта на остальные сервисы.
"Клиент формирует нам Бизнес Требования" — вот это и есть источник проблем. :)))
Подозреваю, среди ваших аналитиков нет хороших специалистов в области фин учёта. И вы вынуждены полагаться на то, что вам говорят сотрудники клиента.
Но проблема в том, что у клиента с очень высокой вероятностью тоже нет специалистов с нужным уровнем квалификации. ))
Близкая аналогия: к инженеру, который разбирается в сплавах и механике, приходит пользователь, который пару лет ездил на автомобиле, и говорит — спроектируй мне автомобиль. О принципах работы и деталях устройства двигателя внутреннего сгорания ни один из них не имеет достаточно глубоких знаний.
Догадываетесь, какой будет результат?
Финансы существенно проще, чем двигатель, но там хватает своих нюансов.
Kafka — более мощный брокер, поддерживающий колоссальное количество транзакций. Но его использование требует более строгой поддержки, ведь его настройка и внедрение гораздо сложнее, чем у того же RabbitMQ. В нашем случае количество транзакций и интеграций пока не достигло такой величины, чтобы вкручивать его в инфраструктуру.
В вашем слушае и RabbitMQ оверхед и достаточно простого NATS, NSQ, да хотя бы Redis Streams.
Так вы только почву подготовили. Самое интересное вас еще только ожидает.
13 лет пилим свою конфигурацию по оперативному и финансовому учету в холдинге на 1с. 13… ЕРП с 0… С 0!!!.. У меня вся жизнь пронеслась перед глазами. Москва писала, писала, потом мы писали, писали. Да будет проклят тот день когда я вообще сел за оперативный учет холдинга. Я стал таким умным что сам себя уже терпеть не могу. ЕРП с 0. Беги.......!!!
Мы только сейчас учетное ядро сформировали. Уже бы плюшки выдавать, но только как говорит, утвердительно, мой знакомый, "Зачем ...", зачем если у тебя уже нет волос на затылке, зачем если жена два раза на лево сходила.
Тут еще прозвучало Клиент. Мне показалось или ты действительно сказал КлиенТ не КлиентЫ а КлиенТ. Мой мозг воспроизвел сейчас столько боли… глаз в смирительной рубашке начал скакать в глазнице. Да вся философия, можно сказать сущность внедрения заключается в том что бы МОЧЬ менять КлиентА на КлиентБ в любой точке. Про точку надо отдельно: тут один 5 лет создает продукт по фиксации точки внедрения(видел бету, обнял). Я слышу твои слова "Зачем..." я знал что ты их скажешь. Да потому что Клиент может, Клиент может, все что угодно… А потом кто Козел? а ты такой раз и карту на стол, вот тут мы, а вот еще что надо, ааа… люди ушли у вас, ну значит карту редактируем и продолжаем. Или так например, деньги закончились, у КлиентА, кто виноват? ТЫ! У тебя ВООБЩЕ ничего не работает. Или у тебя в команде нарцисс распустился, и как давай ходить по конференциям! Такой умный о ляля… И читаешь ты Маргарет Митчелл…
Ну или продали акции: "а нам не надо… " Кому твой продукт еще? Поди поторгуй. Долго ли, коротко ли, а команда уже готова твой мерседес это как его Владимир Александрович сжечь… сжечь… сжечь!!!
Про выбор: тут у тебя все козыри, так как ты не выбрал простой путь в ад от 1с МОСКВА.
Ты скажешь Ресурсы, Саня..., Ресурсы, ты забыл о Ресурсах. Так вот я испытал даже модель когда наша команда стала частью организации. Типа мы все получаем зарплату. Вроде у клиента должен быть перелом парадигмы. Теперь МЫ, теперь НАШЕ, теперь навсегда, мы одно целое. Только вот пишу я сейчас это, и думаю сяду ка я тестировщиком где потеплее, где что то шумит, что бы мозг слышно не было и бокальчик вина и ребенок и коза эта...
PS: если бы угрожали моей семье, то я бы начал так же как ты тут… отличнейшим образом ну ты понял.
ERP на сервисной архитектуре