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 моделерами инструмент.

Ну, ворд, как и карандаш, никто не отменял. (Жаль ундервуды безвозвратно ушли в прошлое.) Ответить на Ваши вопросы в двух словах не получится - слишком в общем виде они сформулированы. Спросите что-нибудь более конкретное. Или приходите (в Вашем случае - приезжайте) в сентябре на конференцию по BPM, там будет и теория, и практические кейсы.

igor250973Да, BPM+SOA позволяют эффективно выполнять ревизию, но это лишь верхний слой работы.
А на более низком уровне вам придётся организовывать взаимодействие различного софта, и вот тут-то и начинаются проблемы, потому что одна программа "немая", а другая "глухая". Тут-то как правило и начинаются конфликты между программистами и аналитиками. Очень верно. Но обязанность программистам и аналитикам делать свою работу никто не отменял. Просто хотелось бы делать ее максимально эффективно и не заниматься явно дурной работой. BPMS (как инструмент) и SOA (как архитектурные принципы) этому способствуют. И позволяют программистам и аналитикам общаться более продуктивно, как говорится, "bridge business-IT gap" . Но заметьте, именно "bridge", а не "eliminate".

byurSOA, BEPL, ESB, MDM и другие buzzwords не сильно помогут ... пока не будет построена внятная модель Enterprise Architecture. Причем в вашем случае имеет смысл построить как модель AS IS, так и модель TO BE. Напомню, что в общем случае EA включает Бизнес-архитектуру, Архитектуру информации и данных, Архитектуру приложений и Технологическую архитектуру (куда входят и сервера приложений, ОС, "железо" и сети). Все начинается с Бизнес-архитектуры. Нужно классифицировать бизнес-процессы (как минимум они должны быть проименованы и иметь приоритет на основании цепочки добавленной стоимости). Отмечу, что при этом можно не описывать динамику самих процессов, а ограничиться только статическим представлением.
Потом определяются важные бизнес-сущности и описываются как эти сущности "гуляют" по процессам и где обрабатываются (архитектура информации в минимальном представлении) и хранятся (уже ближе к архитектуре данных).
После чего составить карту покрытия приложениями тех самых процессов и наложить на нее "гуляние" бизнес-сущностей. Тут можно увидеть ОЧЕНЬ ИНТЕРЕСНУЮ картину ... и по ней сделать чисто экономические выводы об оптимальности ИТ -- почему для одного процесса используется 5 приложений, где "тонкие места" и т.п. Остальное -- показать на каком железе живут приложения и данные.
Кстати тут же можно посчитать TCO :-), и можно даже посчитать ИТ составляющую костов на бизнес-процесс. А уж если замапить это дело еще и на модель ИТ-сервисов (если ITSM внедряли не только в рамках HelpDesk) -- то можно вообще выйти на сервисно-ресурсную модель :-). Чудовищные перспективы ... при таком подходе ИТ-директор может серьезно укрепить свои позиции, и больше не иметь бледного вида при вопросе от CFO "где деньги Зин?"

И только после того, как будет построена модель AS IS -- принимать шаги к оптимизации ИТ архитектуры. Критерием может быть тот же TCO ... Вот тут и станет понятно, без маркетингового bullshit, нужны ли все эти buzzword, или нет ... если нужны (что бывает оправдано) -- то для чего именно и каков их ROI. Теоретически нет возражений, как насчет практики - можете привести пример подобной работы, доведенной до конца? Самим удалось сделать что-нибудь из перечисленного?