Планируется разрабока крупной распределенной системы по управлению сетью производственных предприятий.
Предполагается сложная бизнес-логика, очень большие объемы данных, высокие требования к скорости серверных вычислений и к надежности.
Возникает вопрос, какие средства разработки использовать?
Естественно, кое-каие соображения есть, но хочется услышать мнения общественности.
Кроссплатформенность не требуется. Все должно работать на NT-сервере. Клиенты — тоже под Windows.
— Имеет ли смысл в таких условиях использовать Java для серверной части? Насколько мне известно на западе Java используют в ERP системах среднего масштаба и ниже. Крупный enterprise — область применеия С++. Так ли это? Так же в пользу С++ — требование высокой скорости серверных вычислений.
— Какую использовать базу? Предполагается рапределенное хранилище. Очевидно следует делать выбор между Oracle, DB2 и может быть MS SQL Server
— Клиентские приложения. Ситема закрытая, т.е. количество клиентских мест ограничено. Нет требования возможности доступа к системе с любого компьютера. Это наводит на мысли что клиент может быть построен на GUI. С другой стороны web-клиент упростит ситуацию с модификацией клиентской части.
— Вопрос шифрования данных циркулирующих в системе.
Вобщем вот такие вопросы. Благодарен за любые ответы, мысли, мнения.
Здравствуйте, Slick, Вы писали:
S>Планируется разрабока крупной распределенной системы по управлению сетью производственных предприятий. S>Возникает вопрос, какие средства разработки использовать?
Сейчас я выскажу крамольную мысль и мне понаставят кучу минусов.
Я считаю, что если вы действительно разрабатываете крупную систему предназначенную для больших объемов данныых и т.д. и т.п., то не стоит ее разрабатывать. Надо выбрать и купить что-то готовое максимально приближенное к вам, к вашим бизнес процессам. А потом доработать выбранное с учетом вашей конкретной специфики, тем более, что все современные ERP системы оставляют такую возможность.
Систем сейчас куча и есть из чего выбрать, например — Axapta, Attain, SAP, Baan, Oracle Application, MFG, Галактика, Парус......
Приобретая систему вы получаете минимальную гарантию, что ее уже оттестировали на других предприятиях и фирмах, что она уже прошла хоть какую-то обкатку. Кроме того, вы получаете гарантию, что эту систему будут сопровождать, поддерживать и расширять...
И не считайте сразу, что это дорого. А лучше прикиньте, сколько вам будет стоить собственноручная разработка, плюс тестирование, плюс потери в бизнесе за то время, пока вы пишете эту систему. Учтите также, что вам придется самим сопровождать систему и отслеживать все изменения законодательства...
Опыт подсказывает, что после таких подсчетов корпорации приходят к выводу, что купить готовое дешевле, чем разработать что-то свое.
S>Планируется разрабока крупной распределенной системы по управлению сетью производственных предприятий.
ERP? Значит много формочек, окошек и т.д. и т.п.. Лучшие варианты для клиента, по моему, Builder и Delphi.
S> — Имеет ли смысл в таких условиях использовать Java для серверной части? Насколько мне известно на западе Java используют в ERP системах среднего масштаба и ниже. Крупный enterprise — область применеия С++. Так ли это? Так же в пользу С++ — требование высокой скорости серверных вычислений.
Вообще, лучше писать на том, что привычнее для программистов. Но если до этого Java не сильно использовалась, то лучше сразу переходить на .NET, по крайней мере, для Винды он роднее будет. С#, C++, managed С++, большой разницы в производительности, как показывают тесты, нет. Опять же, что роднее.
S>- Какую использовать базу? Предполагается рапределенное хранилище. Очевидно следует делать выбор между Oracle, DB2 и может быть MS SQL Server
Тоже большой разницы нет, но если идти по пути Microsof, то надо выбирать MS SQL Server.
S>- Клиентские приложения. Ситема закрытая, т.е. количество клиентских мест ограничено. Нет требования возможности доступа к системе с любого компьютера. Это наводит на мысли что клиент может быть построен на GUI. С другой стороны web-клиент упростит ситуацию с модификацией клиентской части.
Web — это очень хорошо и очень удобно, но если нужен действительно очень мощный пользовательский интерфейс, то реализовать его для Web будет гораздо сложнее. И опять же, ориентация на Web означает, что на сервер ляжет очень большая нагрузка, так как те функции, которые могло выполнить GUI-приложение, придётся перенести на сервер, кроме простенькой валидации данных.
S>- Вопрос шифрования данных циркулирующих в системе.
Существует очень много готовых систем шифрования, причём, для каждой платформы, это не самая большая проблема.
DAS> Учтите также, что вам придется самим сопровождать систему и отслеживать все изменения законодательства...
Не в первый раз слышу и никак не могу допереть — зачем в системе планирования ресурсов предприятияотслеживать изменениия закнодательства? Для бухгалтерии понятно, но для ERP или CRM зачем?
Здравствуйте, PeterZT, Вы писали:
DAS>> Учтите также, что вам придется самим сопровождать систему и отслеживать все изменения законодательства... PZT>Не в первый раз слышу и никак не могу допереть — зачем в системе планирования ресурсов предприятияотслеживать изменениия закнодательства? Для бухгалтерии понятно, но для ERP или CRM зачем?
ERP как правило включает в себя и бухгалтерию и оперативный учет, кои от законодательства зависят. А вот CRM кстати обычно не включают в понятие ERP, хотя тесно с ней интегрируют, поскольку это внешний мир, а не ресурсы предприятия.
Здравствуйте, Slick, Вы писали:
S>Планируется разрабока крупной распределенной системы по управлению сетью производственных предприятий.
Мммм... хотя бы порядковые количества узлов?
S>Предполагается сложная бизнес-логика, очень большие объемы данных, высокие требования к скорости серверных вычислений и к надежности.
А конкретнее можно? То, что такие системы, как правило, 24x7 — понятно.
S>Возникает вопрос, какие средства разработки использовать?
S>Естественно, кое-каие соображения есть, но хочется услышать мнения общественности.
S>Кроссплатформенность не требуется. Все должно работать на NT-сервере. Клиенты — тоже под Windows.
Сервере или серверах?
S> — Имеет ли смысл в таких условиях использовать Java для серверной части? Насколько мне известно на западе Java используют в ERP системах среднего масштаба и ниже. Крупный enterprise — область применеия С++. Так ли это? Так же в пользу С++ — требование высокой скорости серверных вычислений.
Посмотри, что-то есть у RogueWave. Они давно в этом направлении копают. Как раз — для поддержки скоростных Enterprise Applications. В России, вроде бы, АйТи у них генеральный дистрибутор или типа того (не сочтите за рекламу).
S>- Какую использовать базу? Предполагается рапределенное хранилище. Очевидно следует делать выбор между Oracle, DB2 и может быть MS SQL Server
Я сам бы предпочёл DB2. Но здесь зависит от требований к системе и бюджета. Хотя, ИМХО, самое лучшее решение — отвязаться от конкретной БД.
S>- Клиентские приложения. Ситема закрытая, т.е. количество клиентских мест ограничено. Нет требования возможности доступа к системе с любого компьютера. Это наводит на мысли что клиент может быть построен на GUI. С другой стороны web-клиент упростит ситуацию с модификацией клиентской части.
На самом деле нет противоречия между клиентом с GUI и Web-клиентом, поскольку и тот и другой могут загружать конфигурацию интерфейса пользователя и осуществлять взаимодействие с сервером, просто отображать UI они будут по-разному. Иными словами — закладывайся на то, что клиент: а) не определён , б) не содержит прикладной логики — вся логика приходит с сервера.
S>- Вопрос шифрования данных циркулирующих в системе.
Внутренний трафик шифруется?
S>Вобщем вот такие вопросы. Благодарен за любые ответы, мысли, мнения.
Сроки? Сколько народу задействовано? Какова их квалификация? Хорошо ли представляете, что хотите получить в итоге?
Ну, пока что вот так вот.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DemAS, Вы писали:
DAS> Опыт подсказывает, что после таких подсчетов корпорации приходят к выводу, что купить готовое дешевле, чем разработать что-то свое.
Так-то оно так, только ситуации разные бывают и пожелания заказчиков — тоже.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Посмотри, что-то есть у RogueWave. Они давно в этом направлении копают. Как раз — для поддержки скоростных Enterprise Applications. В России, вроде бы, АйТи у них генеральный дистрибутор или типа того (не сочтите за рекламу).
Копают давно, но похоже не долго им осталось.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, DemAS, Вы писали:
DAS> Я считаю, что если вы действительно разрабатываете крупную систему предназначенную для больших объемов данныых и т.д. и т.п., то не стоит ее разрабатывать. Надо выбрать и купить что-то готовое максимально приближенное к вам, к вашим бизнес процессам. А потом доработать выбранное с учетом вашей конкретной специфики, тем более, что все современные ERP системы оставляют такую возможность. DAS> Систем сейчас куча и есть из чего выбрать, например — Axapta, Attain, SAP, Baan, Oracle Application, MFG, Галактика, Парус......
Обычно редко какая-либо из них сможет удовлетворить все потребности предприятия, особенно с динамично развивающимся бизнесом. К тому же такие системы тоже требуют настройки и сопровождения, и очень часто не меньшей. Отдел IT в 50 человек на предприятиях где используется, наприр, R3, обычное дело. Моё ИМХО — готовые системы использовать надо, но только как часть системы предприятия. Такие системы не должны быть основой системы предприятия и должны в неё легко интегрироваться. В таком случае, если такая штука чего-то не умеет, то всегда можно будет это что-то дописать. А вот если это вещь в себе, то отстёгивать консультантам за настройку или разработчикам за дороботки придётся не мало.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, PeterZT, Вы писали:
AVK>>ERP как правило включает в себя и бухгалтерию и оперативный учет, кои от законодательства зависят. PZT>Оперативный учет как зависит ?
Здравствуйте, AndrewVK, Вы писали: PZT>>Оперативный учет как зависит ? AVK>Ну например НСП.
Понятно. Но все же не так сильно, как бухгалтерия, т.е. оперативный учет можно держать в соответствии с законом намного меньшими усилиями, чем бухгалтерию.
Здравствуйте, IT, Вы писали:
ГВ>>Посмотри, что-то есть у RogueWave. Они давно в этом направлении копают. Как раз — для поддержки скоростных Enterprise Applications. В России, вроде бы, АйТи у них генеральный дистрибутор или типа того (не сочтите за рекламу).
IT>Копают давно, но похоже не долго им осталось.
С чего ты так решил?
На NASDAQ они сейчас растут существенно быстрее, чем Microsoft. (RWAV, MSFT)
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
AVK>>Чего, докопались до трупа?
IT>Типа того. Стингреевскую библиотеку совсем сгноили, на .NET забили, разработчики разбегаются, менеджмент докладывает инвесторам о новых победах.
А откуда такая информация? Релизы новые аккуратно появляются
Здравствуйте, DemAS, Вы писали:
DAS> Я считаю, что если вы действительно разрабатываете крупную систему предназначенную для больших объемов данныых и т.д. и т.п., то не стоит ее разрабатывать. Надо выбрать и купить что-то готовое максимально приближенное к вам, к вашим бизнес процессам. А потом доработать выбранное с учетом вашей конкретной специфики, тем более, что все современные ERP системы оставляют такую возможность.
Вообще-то когда речь идет о действительно крупной системе управления большим предприятием такой подход неприемлем.
Уже не раз в этом убеждался.
Все эти готовые усредненыые решения подходят для не очень больших предриятий с типичными бизнес-процессами. В крупных предприятиях, в промышленности внутренние процессы настолько сложны и специфичны что адаптировать под них что-то существующее — себе дороже.
А если говорить про конкретный случай, тот здесь это даже не обсуждается. Решение о собственной разработке уже принято и варианты с использованием существующих ERP не рассматриваются. Решаются вопросы планирования, проектирования временной оценки и необходимых средств разработки.
Буду благодарен за помощь в решении именно этих вопросов.
Здравствуйте, Геннадий Васильев, Вы писали:
IT>>Копают давно, но похоже не долго им осталось.
ГВ>С чего ты так решил?
ГВ>На NASDAQ они сейчас растут существенно быстрее, чем Microsoft. (RWAV, MSFT)
Если у тебя есть их акции, то срочно беги продавай
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, kavlad, Вы писали:
IT>>Типа того. Стингреевскую библиотеку совсем сгноили, на .NET забили, разработчики разбегаются, менеджмент докладывает инвесторам о новых победах.
K>А откуда такая информация? Релизы новые аккуратно появляются
А в релизах что-нибудь новое появляется?
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
S>Вообще-то когда речь идет о действительно крупной системе управления большим предприятием такой подход неприемлем. S>Уже не раз в этом убеждался.
S>Все эти готовые усредненыые решения подходят для не очень больших предриятий с типичными бизнес-процессами. В крупных предприятиях, в промышленности внутренние процессы настолько сложны и специфичны что адаптировать под них что-то существующее — себе дороже.
Да, а такие компании как РосТлеком, Ленсвязь, Toyota, Энергомаш, Перекресток, Исток, Волгоградский Аллюминий, MTV, Marvel, Osko, Алтайагропромснаб, Гипермаркет О"Кей, Группа компаний DIXIS, ДелтаСпорт, Останкинский молочный комбинат, Первоуральский новотрубный завод, РУССО, Ригла, Техносила, Тинькофф — это я говорю про тех людей, которые выбрали Axapt'у. Про другие системы не буду рассказывать, так как не очень с ними знаком. Это по твоему мелкие компании ?
S>А если говорить про конкретный случай, тот здесь это даже не обсуждается. Решение о собственной разработке уже принято и варианты с использованием существующих ERP не рассматриваются. Решаются вопросы планирования, проектирования временной оценки и необходимых средств разработки. S>Буду благодарен за помощь в решении именно этих вопросов.
А вот тут как раз обсуждать то и нечего . Либо ты можешь это делать, либо нет — обсуждениями здесь дело не поправишь.
, б) не содержит прикладной логики — вся логика приходит с сервера.
Если нам не помогут, то мы тоже никого не пощадим.
