Тут ведь вопрос обычно в том, насколько язык/платформа позволяют минимизировать количество связей между сущностями из разных модулей.
Количество связей ведь определяет бизнес-задача. Модули и объекты это всего лишь способ описания их взаимодействия и интерфейс для манипуляции ими. Модули сами по себе не существуют. И проблема в том, что может платформа и позволяет, но задачи которые с её помощью решаются в большинстве случаев разделению поддаются очень плохо.
Например автомобиль. Вроде все сделано модульно, хочешь стекла не ставь (на юге ездишь). Хочешь сидения назад не ставь (ездишь только в двоём. Вроде много можно «убрать». Но многие вещи типа колёса, двигатель, коробка передач, полный привод или только передний или задний просто так не поменяешь. Программы они конечно более гибкие, но от этого проблема связи легче не становится, т.к. этих самых связей становится еще больше.
А вы уже настолько глубоко попробовали lsFusion, что можете делать такие выводы?
Проблема модульности не в используемой платформе. Проблема в самой идее. Модули это значит зафиксированные связи между модулями, убрать модуль на который кто-то рассчитывает нельзя, нужно делать заглушку или замену и в результате модуль «потребитель» должен всегда быть готов что на «другом» конце нужного нет. В результате реализовывать это все очень накладно, нужно не только логику реализовать, но и все возможные варианты связи.
Итого в 4 раза больше сделаете и в 2 раза больше заработаете
Это при неограниченном спросе. Вы ведь понимаете что спрос по большей части сейчас весь удовлетворён.
А когда вы станете монополистом, половине тех кто сейчас этим занимается нужно будет менять сферу деятельности.
То что его где-то можно разрезать != разрезать можно там где хочешь. Но это всегда умалчивается при продаже «модульности». По факту для конечного пользователя выбор какие модули включать, а какие нет достаточно ограничен. Можно конечно купить машину без тахометра, но не поменяв при этом «торпеду» ездить с «дыркой» на месте тахометра никто не захочет.
Ну так со временем верхние модули будут требовать много других. В результате «подключаемыми» по желанию будут только те, на которые никто не ссылается. А это обычно совсем небольшие по функционалу вещи.
Ну и в догонку, в 1С это тоже есть уже несколько лет. Называется «расширение».
Еще модульность (это один из важных кейсов, причем как вертикальная, так и горизонтальная, то есть поставляются только те модули что нужно
Вот это в маркетинге мне всегда нравилось. )))
«Наша система модульная, какой хочешь модуль, тот и подключаешь». Ага, а зависимости между модулями? И их синергия?
«А модуль Бух учета хочу, Модуль казначейства хочу, а модуль номенклатуры нет.» Как кто в этом случае будет все эти связи учитывать? А то что одни модули влияют на интерфейс и функции других модулей?
Вы в денежном или количественном выражении?
Ведь если 10% это 100 клиентов, а 90 это 10000 то позиции совершенно разные. Кто в этом случае «крепче» стоит на ногах можно поспорить.
Большинство реклам начинаются с показов проблем (типа рвется рубашка, что-то липнет и т.п.)
Да, но там сравнивают с «Обычным стиральным порошком».
Преимущества обратная сторона недостатков
Тогда опишите свои недостатки.
Ваша реклама на хабре для кого? Кого пытаетесь привлечь? Конечный потребитель суда заходит редко. Переманить на свою сторону «армию» 1С-ников? Многие ваши примеры для большинства 1С-ников не являются проблемой из-за которой они должны менять свой основной инструмент (превращение 1С в почти монополию тому доказательство). В результате те 1С-сники что хорошо знают свой инструмент и более активны чем остальные, становятся скорее вашими противниками чем сторонниками.
1С и lsFusion это инструмент для зарабатывания денег. Люди готовы менять инструмент только если он будет приносить им больший доход. Лучше покажите на примере «абстрактного» внедренца, почему он будет зарабатывать больше.
Из практики, больше всего проблеме из-за структурных различий в интегрируемых системах. Например неоднозначные связи (один и тот же объект источник может загружаться в разные приемники), архитектурные различия в обработке данных (одна система поддерживает работу «задним числом, а другая нет). Таких проблемы бывают конечно всегда, но при интеграции систем сделанных на одной платформе, или еще лучше одним поставщиком, этих проблему будет существенно меньше.
А зачем вы сравниваете свое решение с 1С? Хотите сделать рекламу «нападением» на армию 1С-ников, которых, думаю существенно больше? Пытаться «выехать» за счет «унижения» другого не самый честный способ (хотя думаю унизить будет сложно, все же 1С хорошая платформа для решения задач для которых она предназначена). Многие 1С-ники сами не в восторге от своего инструмента, но им она даёт больше чем другие. И многим будет интересно просто узнать про возможности других систем.
Например 1С на хабре не занимается сравнением себя с другими, а просто пишут (мало) что и почему они делают.
С чего вы взяли что весь «головняк» из-за работы задним числом?
UPD:
«С чего взяли» догадываюсь. Но опыт показывает, что это не самая большая проблема.
Разница в том, что этот «один» поставщик точно имеет актуальную информацию по планам развития и оперативно актуализирует это самую «интеграцию». Когда поставщика 2, один обязательно «прошляпит» изменения у другого.
lsFusion и 1С это платформы для создания прикладных решений. Следовательно важны не они сами по себе, а прикладные решения который создаются с их использованием. Главная цель для них это «нести» пользу конечному пользователю. Потребители по большому счёту не важно на чем он работает. По этому показателю 1С является лидером. Конкуренция с 1С начнется только тогда, когда конечному потребителю будут предоставлены все те же удобства что он имеет сейчас.
Для бухгалтера важно соответствие законодательству. С 1С он может за 10 мин зарегистрироваться на 1cfresh.com и доступ облачному решению которое всегда актуально, и ему не нужно думать ни о чем, он просто пользуется, даже устанавливать ничего не надо.
Для руководителя предприятия при внедрении ERP важно найти максимально подходящее под его требования решение и иметь возможность за минимальные деньги и сроки реализовать все необходимые «доработки».
Для них слова «мы нагружаем СУБД и не сервер приложения» не важны.
Так любая интеграция это большая головная боль. Особенно когда интегрируемые системы развиваются независимо в своих интересах. Кто будет заниматься актуализацией? В результате, какой заказчик захочет жить в условиях постоянной опасности что в один прекрасный день, что-то может не работать?
1С это для бухгалтера. Если нужна какая-то другая автоматизация нужно отдельное специализированное решение адаптированное под предметную область.
Это у вас опыт внедрения и того и того говорит?
на каком-то мейнстримовом языке вроде java/c#/go
Решение делается ведь не на языке. Язык не важен. Важен фреймворк на котором сделано решение. Писать под каждое решение свой фреёмворк точно не в интересах конечного заказчика.
Вы себе представляете что это такое? Думаете он так вот сел, и решил посчитать налоги и все? Думаете ему ничего из «управленческих» данных ничего для этого не нужно? Ему это как вводить, вручную?
Количество связей ведь определяет бизнес-задача. Модули и объекты это всего лишь способ описания их взаимодействия и интерфейс для манипуляции ими. Модули сами по себе не существуют. И проблема в том, что может платформа и позволяет, но задачи которые с её помощью решаются в большинстве случаев разделению поддаются очень плохо.
Например автомобиль. Вроде все сделано модульно, хочешь стекла не ставь (на юге ездишь). Хочешь сидения назад не ставь (ездишь только в двоём. Вроде много можно «убрать». Но многие вещи типа колёса, двигатель, коробка передач, полный привод или только передний или задний просто так не поменяешь. Программы они конечно более гибкие, но от этого проблема связи легче не становится, т.к. этих самых связей становится еще больше.
Проблема модульности не в используемой платформе. Проблема в самой идее. Модули это значит зафиксированные связи между модулями, убрать модуль на который кто-то рассчитывает нельзя, нужно делать заглушку или замену и в результате модуль «потребитель» должен всегда быть готов что на «другом» конце нужного нет. В результате реализовывать это все очень накладно, нужно не только логику реализовать, но и все возможные варианты связи.
Это при неограниченном спросе. Вы ведь понимаете что спрос по большей части сейчас весь удовлетворён.
А когда вы станете монополистом, половине тех кто сейчас этим занимается нужно будет менять сферу деятельности.
Тогда это совсем не про платформу.
То что его где-то можно разрезать != разрезать можно там где хочешь. Но это всегда умалчивается при продаже «модульности». По факту для конечного пользователя выбор какие модули включать, а какие нет достаточно ограничен. Можно конечно купить машину без тахометра, но не поменяв при этом «торпеду» ездить с «дыркой» на месте тахометра никто не захочет.
Ну и в догонку, в 1С это тоже есть уже несколько лет. Называется «расширение».
Вот это в маркетинге мне всегда нравилось. )))
«Наша система модульная, какой хочешь модуль, тот и подключаешь». Ага, а зависимости между модулями? И их синергия?
«А модуль Бух учета хочу, Модуль казначейства хочу, а модуль номенклатуры нет.» Как кто в этом случае будет все эти связи учитывать? А то что одни модули влияют на интерфейс и функции других модулей?
Вы в денежном или количественном выражении?
Ведь если 10% это 100 клиентов, а 90 это 10000 то позиции совершенно разные. Кто в этом случае «крепче» стоит на ногах можно поспорить.
Да, но там сравнивают с «Обычным стиральным порошком».
Тогда опишите свои недостатки.
Ваша реклама на хабре для кого? Кого пытаетесь привлечь? Конечный потребитель суда заходит редко. Переманить на свою сторону «армию» 1С-ников? Многие ваши примеры для большинства 1С-ников не являются проблемой из-за которой они должны менять свой основной инструмент (превращение 1С в почти монополию тому доказательство). В результате те 1С-сники что хорошо знают свой инструмент и более активны чем остальные, становятся скорее вашими противниками чем сторонниками.
1С и lsFusion это инструмент для зарабатывания денег. Люди готовы менять инструмент только если он будет приносить им больший доход. Лучше покажите на примере «абстрактного» внедренца, почему он будет зарабатывать больше.
Например 1С на хабре не занимается сравнением себя с другими, а просто пишут (мало) что и почему они делают.
UPD:
«С чего взяли» догадываюсь. Но опыт показывает, что это не самая большая проблема.
Для бухгалтера важно соответствие законодательству. С 1С он может за 10 мин зарегистрироваться на 1cfresh.com и доступ облачному решению которое всегда актуально, и ему не нужно думать ни о чем, он просто пользуется, даже устанавливать ничего не надо.
Для руководителя предприятия при внедрении ERP важно найти максимально подходящее под его требования решение и иметь возможность за минимальные деньги и сроки реализовать все необходимые «доработки».
Для них слова «мы нагружаем СУБД и не сервер приложения» не важны.
Это у вас опыт внедрения и того и того говорит?
Решение делается ведь не на языке. Язык не важен. Важен фреймворк на котором сделано решение. Писать под каждое решение свой фреёмворк точно не в интересах конечного заказчика.
И эту фильтрацию нужно делать в каждом месте? А если её нужно подкорректировать?
Вы себе представляете что это такое? Думаете он так вот сел, и решил посчитать налоги и все? Думаете ему ничего из «управленческих» данных ничего для этого не нужно? Ему это как вводить, вручную?