Petro123должен быть "генеральный конструктор" ИС\БД. Тогда не будет зоопарка (1С особый случай) Не понял, кто кому что должен??? Предприятия и системы живут дольше, чем люди работают на одном месте. Бесполезно говорить что зоопарка быть не должно, если он уже есть по факту. "1С особый случай" - а парус, галактика, сап или сэйлсфорс не особые что ли случаи?

Ключевые слова, которые необходимо знать прежде чем принимать какие-то решения для данной задачи - ESB, SOA, MDM, BPM. Гуглите.

shelsoftУ Николая Носова, детского писателя, автора Незнайки, были персонажи - Доктор Пилюлькин (лечил всех исключительно касторкой) и Доктор Медуница (адекватно использовала мед). Никто не будет возражать если ему пропишут мед. Но только при условии, что Доктор знает о существовании других лекарственных средств помимо меда. Включая касторку. Так что давайте без крайностей. Изобретать велосипед - такой же грех, как глотать таблетки, не обращаясь к врачу. Я лично вовсе не призывал топикстартера использовать то или иное средство. Но знать об их существовании, назначении и возможностях полагаю обязательным. Так же как знать зверей в своем зоопарке - но это знание у топикстартера я полагаю наличествует и без подсказок извне.

servicemix не примеряли?

Шо делать дальше? АБservicemix не примеряли?
Неа - OpenESB Ну и...?

Шо делать дальше?См. выше. Не понял: OpenESB не имеет коннекторов к БД?

Шо делать дальше?Разумеется имеет - есть JBI компоненты, можно заделать свой сервис для работы с БД. Проблема не в этом - она ниже уровнем, в зоопарке различных систем, именно поэтому хочу найти готовый или написать свой агрегатор данных с плагинами, который бы выковыривал данные из разных истчников и сводил в одну базу. Вот и интересуюсь - делал ли кто-нибудь что-то подобное? Получается похоже на MDM?

Шо делать дальше? АБПолучается похоже на MDM?
Что за зверь? А то гугл постоянно ссылки на какие-то банки выдает....

Master Data Management . Сейчас все главные вендоры его активно толкают. Купить врядли получится, дорого, но познакомиться на уровне концепций/demo/evaluation наверное имеет смысл. Есть ли опенсорсная альтернатива не знаю, не изучал.

директора задолбали молчатьДайте нормальную стратегию развития компании на десять лет вперед, а то получается что итшники последними узнают о расширении на 100% фирмы в ближайший год, а в текущей ситуации имеется лишь лоскутная автоматизация в последней стадии, как у топикастера, при этом полномочий повлиять не ситуацию нету никаких
(приостановить расширение, настоять на покупке готовой системы и реорганизации под нее бизнеса).
Вот и пляшут итшники как в жопу раненые.... Смешно, право: Вы видимо считаете директоров какими-то небожителями. Какое там - "Человек предполагает, а господь располагает".

Они рады бы спланировать все на 10 лет, но не получается; директора живут на вулкане точно так же, как и айтишники: собственники, конкуренты, правительство подкидывают вводные, на которые приходится реагировать. Ну да, бывает что могли заранее спланировать, но недотумкали или поленились. Но сплошь и рядом в бизнесе приходится действовать по ситуации. Неопределенность в бизнесе существует объективно - "туман войны" по Клаузевицу.

директора задолбали молчатья очень хочу чтобы наша профессия со временем стала такой же инженерной дисциплиной как например строительство - вам нужно здание? Извольте заплатить за проект, а потом за возведение, или покупайте (арендуйте) готовое, но тут уж не выдвигайте требований пристроить к нему еще 30 этажей. Изволили построить времянку, а теперь хотите ее превратить в доменный цех? нет проблем - СНОСИМ временку и строим цех. Через пять лет вам потребуется переделать цех в аэропорт? Это ваши трудности - х*й в голове медецина бессильна. Вы никогда не задумывались почему в IT такой процент проваленных проектов (представьте себе такой процент например в автомобилестроениии)? А потому, что делают их не в рамках инженерного подхода, а вопреки ему.... И заметьте, никто не кричит "Судостроители пи...сы не хотят переделать речной трамвайчик в ледокол". Ээээх мечты... А Вам не приходило в голову, что компьютергная программа - объект существенно отличающийся от здания или судна? В случае здания или корабля у вас есть проектирование, когда объект "строится" на бумаге или в CADе, и собственно производство, когда закупаются материалы и объект изготавливается "в железе". С этой точки зрения изготовление программы целиком укладывается в проектирование, а производства как такового нет.

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

Шо делать дальше? АБ А Вам не приходило в голову, что компьютергная программа - объект существенно отличающийся от здания или судна? В случае здания или корабля у вас есть проектирование, когда объект "строится" на бумаге или в CADе, и собственно производство, когда закупаются материалы и объект изготавливается "в железе". С этой точки зрения изготовление программы целиком укладывается в проектирование, а производства как такового нет.

Он отличается ровно до тех пор, пока не запущен в эксплуатацию и в нем не появились живые данные, а потом уже все не так просто.... В истории кораблестроения есть примеры, когда готовый на 85% линкор перестраивался в авианосец. Что по сравнению с этим преобразование каких-то данных :)

Для справки: цена линкора измеряется миллиардами долларов. Что, заказчики были тупыми? Нет, поменялась военно-стратегическая обстановка, тактика и вооружение противника. То же и в бизнесе: пока мы думали об управленческом учете, кокуренты успели обзавестись CRM-ом. А айтишники за пивом рассуждают: "ну директора у нас тууупые!" :)

igor250973Много красивых бывает словей... там всякие такие SOA, BPML и т.д. и т.п. Да только в конечном счёте всё сводится к межпрограммному взаимодействию, а как прикажете взаимодействовать программам, изначально для этого не предназначенным? Ломитесь в открытую дверь, уважаемый. Ясно что никакая аббревиатура из 3 или даже 4 букв не изменит существующих программ. Что выросло, то выросло. Но она может указать направление, по которому надо идти, чтобы избежать подобных проблем в будущем.

igor250973Так что я бы советывал (опираясь в том числе и на свой опыт) начать с построения и анализа банальных диаграмм бизнес-процессов (реализуемых посредством наличествующих систем) и потоков данных. ОК, но насколько именно банальных? Тут можно воспользоваться инструментарием и методологией 20-летней давности, а можно более современными, поддерживающими к примеру SOA, BPMN и agile методологию. Если кроме "динозавров" у организации есть/будут какие-то современные программы, то наверное стоит выбирать что-то из современных средств управления бизнес-процессами.

igor250973Строить необходимо на нормальной площадке, заложив соответствующий фундамент. Поэтому я и предложил человеку начать с ревизии имеющихся бизнес-процессов и поддерживающего их софта, а далее произвести необходимый реинжиниринг, без чего у вас дальнейшие шаги ну никак не получаться. Согласен, но вопрос в том, что считать "нормальной площадкой". Я утверждаю, что BPM+SOA как раз и позволяет и эффективно выполнять ревизию, за которую Вы ратуете, и развиваться дальше. А Вы что считаете "нормальной площадкой и фундаментом"? Диаграммы IDEF?

igor250973SOA в чистом виде - концепция, но её одной недостаточно. Собственно, тут нечего доказывать, это аксиома. Буква "A" в SOA означает "Архитектура", а к архитектуре нужна технология. Технологие могут быть самыми разнообразными. Например, в качестве примеров реализации SOA иногда приводят банковские интеграционные решения, разработанные чуть ли не в 80-е, когда и термина-то такого не было.

igor250973Я считаю что проектирование имеет дело с абстракциями разных уровней и бизнес-процессный подход вкупе с сервис-ориентированной концепцией - только вершина айсберга. на определённых уровнях понадобятся и IDEF и UML. Понятно, что UML на своем уровне вещь замечательная. Но если вернуться к Вашему призыву начать с ревизии всего и вся (процессов и систем), то уверяю Вас, для этой задачи современные BPMS - более совершенный по сравнению с IDEF и UML моделерами инструмент.