Вопрос про новизну технологий: Agile+scrum+transition to CRM/ERP

[Helmsman]

При чём тут железо? Система, с которой я работаю, начиналась на юниксе и каком-то железе от HP 30 лет назад. В прошлом году её портировали на линукс и новое железо, но новомодные инструменты с ней так же не работают, как и раньше.

[SVK]

Мда. Мы не в Америке живем (а чуток северней). Но все происходит почти также. Хотя... мейнфреймы, по моему, все уничтожили.

Это так выглядит, если смотреть на айсберг сверху. А можно также поднырнуть под воду.

Top 20 Mainframe Software Suppliers

Six Major Industries Still Use Mainframes Extensively:

- Banking
- Retail
- Insurance
- Healthcare
- Government
- Travel and Transportation

mainframes are still gainfully employed at:

- All 10 of the world’s largest insurers
- 92 of the world’s top 100 banks
- 90% of all credit card transactions are processed on mainframes
- 18 of the top 25 retailers
- 70% of the Fortune 500
- 68% of the world’s production IT workloads

[Easbayguy]

Ха, я в 2005 году в конторе переводил из Информикса в Оракл. И куда я только за 18 лет потом из оракла не мигрировал данные, в мysql, постгресс, монго, кассандру, динамодб. И какое оно все гавнистое и дорогое! Как только отдали на откуп командам разработчиков, что использовать для разработки, так сразу траты на базы раздулись в несколько раз!

[zVlad]

Я не апологет agile, но не понимаю чего люди его костерят.
Это инструмент. Плохой он или хороший зависит от рук.
Если менеджер мудак ему любой инструмент в руки дай он мудаком останется.

А мне кажется что есть и обратная связь. Обученные agile менеджеры неизбежно становятся мудаками.
Т.е. если бы их ничему не учили, то те из них у кого есть мозги сами бы нашли свой метод в конкретной ситуации.
Тоже самое и с девелоперами происходит. Их учат приемам работы заложенным в конкретный продукт для программирования. Не программированию учат, а как использовать тул. Что из этого может получиться? Ничего хорошего.
Исправлять ошибки обучения пытаются не улучшая само обучение, а созданием методик которые по мнению их создателей исправляет обученных неправильно работников.
Замкнутый круг.

[zVlad]

Джавы и питоны приходят и уходят, а мэйнфреймы остаются…

Мда. Мы не в Америке живем (а чуток северней). Но все происходит почти также. Хотя... мейнфреймы, по моему, все уничтожили.

Нет не все мэйнфрэймы чуток севернее уничтожили. Их есть еще. Я недавно пересекался с ИБМ техником обслуживающим зону Маркхам (Toronto GTA). Спросил есть ли у него здесь пользователи z16. Есть говорит. Z16 это семейство МФ появившееся год назад.
Но два МФ уничтожаются с моим активнейшим участием. Участвую в миграции данных из CA-IDMS на SQL Server. Делаю это через DB2 for zOS и репликацию далее.

[Плюшка]

Не знаю про Торонто. Но в столице нашей родины, если и осталось то только в глубинах Ревнивой. Кобол там до сих пор лютует, говорят.

[zVlad]

Для успеха перевода приложений с мэйнфрэймов нужно, в первую очередь, иметь достаточное количество заинтересованных в переводе, хороших специалистов по мэйнфрэйм.
Не кого-нибудь кто когда-то что-то делал на мэйнфрэйм, а постоянно работающих на МФ, знающих МФ, и заинтересованных в теме.

[zVlad]

..... И если в тех конторах где-то мейнфреймы остались, то не дай бог их тронуть. Ибо главный страх высших манагеров - какбы оно не упало вдруг. И не на пару часов, а на пару суток. А значит - любые предложения как нам слегка улучшить применив "новомодные технологии" - отметаются ими с порога. ....

По поводу "какбы оно не упало вдруг" скажу что на самом деле манагеры, если это образованные манагеры, знают что последнее что упадет это мэйнфрэйм. По-этому чем больше ИТ остается на МФ тем в целом ИТ остается устойчевие и надежнее.
Не как манагер, им я не являюсь, а как специалист по МФ скажу что любые рациональные "новомодные технологии" есть и на МФ и если они могут что-то улучшать я лично всегда был рад посодействовать их применению. Примеры: WebSphere, Linux, Java, виртальные машины на МФ появились за долго до их появления где-либо еще.
Но, что Вы понимаете под словом "мэйнфрэйм"? Спрашиваю потому что бывает что это не то о чем я обычно говорю здесь. Не удивлюсь что найдутся нынче что и Sun под Salaris назовут мэйнфрэймом. Надеюсь Вы не те.

[mavr]

Я не апологет agile, но не понимаю чего люди его костерят.
Это инструмент. Плохой он или хороший зависит от рук.
Если менеджер мудак ему любой инструмент в руки дай он мудаком останется.

А мне кажется что есть и обратная связь. Обученные agile менеджеры неизбежно становятся мудаками.

Одно это заявление ставит вас в один ряд с такими менеджерами.

[zVlad]

Я не апологет agile, но не понимаю чего люди его костерят.
Это инструмент. Плохой он или хороший зависит от рук.
Если менеджер мудак ему любой инструмент в руки дай он мудаком останется.

А мне кажется что есть и обратная связь. Обученные agile менеджеры неизбежно становятся мудаками.

Одно это заявление ставит вас в один ряд с такими менеджерами.

Я не менеджер.

[Плюшка]

..... И если в тех конторах где-то мейнфреймы остались, то не дай бог их тронуть. Ибо главный страх высших манагеров - какбы оно не упало вдруг. И не на пару часов, а на пару суток. А значит - любые предложения как нам слегка улучшить применив "новомодные технологии" - отметаются ими с порога. ....

По поводу "какбы оно не упало вдруг" скажу что на самом деле манагеры, если это образованные манагеры, знают что последнее что упадет это мэйнфрэйм. По-этому чем больше ИТ остается на МФ тем в целом ИТ остается устойчевие и надежнее.
Не как манагер, им я не являюсь, а как специалист по МФ скажу что любые рациональные "новомодные технологии" есть и на МФ и если они могут что-то улучшать я лично всегда был рад посодействовать их применению. Примеры: WebSphere, Linux, Java, виртальные машины на МФ появились за долго до их появления где-либо еще.
Но, что Вы понимаете под словом "мэйнфрэйм"? Спрашиваю потому что бывает что это не то о чем я обычно говорю здесь. Не удивлюсь что найдутся нынче что и Sun под Salaris назовут мэйнфрэймом. Надеюсь Вы не те.

нам, татарам, все равно. Любой ящик увеличенных размеров, который не под Виндами - уже мейнфрейм.

[zVlad]

...
нам, татарам, все равно. Любой ящик увеличенных размеров, который не под Виндами - уже мейнфрейм.

Вот и я об этом. Говорят люди про мэйнфрэймы и не знают что это такое.

[Плюшка]

Для успеха перевода приложений с мэйнфрэймов нужно, в первую очередь, иметь достаточное количество заинтересованных в переводе, хороших специалистов по мэйнфрэйм.
Не кого-нибудь кто когда-то что-то делал на мэйнфрэйм, а постоянно работающих на МФ, знающих МФ, и заинтересованных в теме.

Может, у вас, в Торонто оно и так.
А у нас, в столице, как и в марксизме, нужны все три составные части:
1. Высшие гос-манагеры, которые неслабые финансы одобрят из вечно-урезаемого госбюджета.
2. Среднего уровня гос-манагеры - которым захотелось карьеру сделать на разработке новизны из старины.
3. И команда реальных разработчиков-контракторов, которые лыко вяжут и фишку рубят. Впрочем, таковых давно я не видал.

[Плюшка]

...
нам, татарам, все равно. Любой ящик увеличенных размеров, который не под Виндами - уже мейнфрейм.

Вот и я об этом. Говорят люди про мэйнфрэймы и не знают что это такое.

Было время, был я молод. Мейнфремов немало повидал.

[Palych]

Для успеха перевода приложений с мэйнфрэймов нужно, в первую очередь, иметь достаточное количество заинтересованных в переводе, хороших специалистов по мэйнфрэйм.
Не кого-нибудь кто когда-то что-то делал на мэйнфрэйм, а постоянно работающих на МФ, знающих МФ, и заинтересованных в теме.

Может, у вас, в Торонто оно и так.
А у нас, в столице, как и в марксизме, нужны все три составные части:
1. Высшие гос-манагеры, которые неслабые финансы одобрят из вечно-урезаемого госбюджета.
2. Среднего уровня гос-манагеры - которым захотелось карьеру сделать на разработке новизны из старины.
3. И команда реальных разработчиков-контракторов, которые лыко вяжут и фишку рубят. Впрочем, таковых давно я не видал.

КМК никакие манагеры, никакие деньги не заменят главной составной части: детального знания того что приложение делает и что оно должно делать.
Неведение сего и есть главный двигатель КОБОЛизации систем.
"...и вдруг нам становится страшно что-то менять"

[zVlad]

...
нам, татарам, все равно. Любой ящик увеличенных размеров, который не под Виндами - уже мейнфрейм.

Вот и я об этом. Говорят люди про мэйнфрэймы и не знают что это такое.

Было время, был я молод. Мейнфремов немало повидал.

Повидать то повидал, но, судя по всему, не понял что.

[zVlad]

...
КМК никакие манагеры, никакие деньги не заменят главной составной части: детального знания того что приложение делает и что оно должно делать.
Неведение сего и есть главный двигатель КОБОЛизации систем.
"...и вдруг нам становится страшно что-то менять"

Вот мы сейчас занимаемся типа "декоболизацией".
Есть один товарищ, говорят ему за 70, который много лет приложение написанное, нет не только на Коболе, сопровождал (вносил изменения по запросам бизнеса). Не думаю что он был отцом этого приложения, хотя приложение домашнее.
Есть группа девелоперов во главе с несколькими менеджерами и бизнес аналитиками. Есть пользователи этого приложения участвующие в переносе приложения.
Товарищ, которому за 70 (говорят), пару лет занимается миграцией данных БД с МФ на сиквел. Исходная БД не реляционная. Товарищ что-то пытается сделать изменить в структуре данных и сделать ее более реляционной, пытается изменить связи, названия и никто не знает что еще. В итоге у него данные оказываются в таблицах сиквела. Им придуманных таблицах.
С этих таблиц девелоперы пытаются что-то написать. И написали уже по видимому не мало. Критерием правильности написанного является сравнение с тех что показывает старое приложение на МФ (приложение имеет диалоговую часть и в принципе ее тот пересоздают девелоперы).
Таблицы, придуманные товарищем, девелоперам не нравятся и они придумали свои (по большому счету те же яйца только вид сбоку) и после завершения миграции данных товарища они делают свою миграцию из его таблиц в свои. Да и еще надо добавить что у товарища на сиквеле (кстати заметьте товарищ с МФ вовсю рассекает на сиквеле, в Виндусах. Сам копирует данные созданные им на МФ, сам их грузит в созданые им таблицы, сам пишет на T-SQL хранимые процедуры "трансформации". Их у него уже десятки написано) так вот у товарища два набора таблиц. В один (называется temporary) он грузит напрямую то что создал на МФ, затем из этих, хранимыми процедурами, переписывает данные во второй набор, из которого девелоперы наполняют свои таблицы.
Девелоперы панически боятся совать носы на МФ. Менеджеры запросили создать им аккаунты, их создали, есть инструкция к приложению. Девелоперов на МФ нет. У них есть один пользователь (просто пользователь) ее они и просят посмотреть.
Есть документ по приложению. Больше сотни страниц. Основы на первых трех изложены. Далее как плавать по диалогам приложения для разных функций и поводов.
Основы написаны примерно в таком стиле: "Главным элементом является "структура". Есть 4 вида структур. У двух из их есть варианты. Вы можете подумать что всего их 6, но на самом деле их семь...." И далее туманное объяснение почему семь.
Или. "Есть "wire" на самом деле это "wire number", которые объединены в "wire blocks".
А еще есть "elementary wire diagram"s, work plans, terminals, terminations, connectors, connections, и наконец и конечно же cables.
Особо интересная история с терминалами. Их может быть четыре вида обозначаемые +1, -1, +2, и -2. Больше четырех "system doesn't allow to have". Так написано. Но оказывается есть ситуации когда надо больше. Тогда создаётся "fake structure" (которые вообще должны быть уникальными и поэтому в их имя добавляется "+"). С этим фэйком товарищ при переносе данных с МФ борется (merge structure). Но недавно, когда они долго отсутствовал, девелоперы всерьез просили меня вернуть фэйковые структуры (demerge structure).

К чему я все это написал? К тому чтобы показать что на самом деле порой проблема вовсе не Коболе и не в МФ как таковом. Проблема в заложенных в приложение изначально дефектах. Поскольку приложения писались долго и у них были сначала простые требования и функции которые далее добавлялись и изменялись, то в итоге все дефекты были так или иначе обойдены, утрясены. Копировать же все это весьма затруднительно. Что мы и имеем сейчас.

Можно подумать что такое может быть только на МФ, только потому что Кобол. Ничего подобного. Куча приложений написанных не на МФ и не на Коболе с которыми точно также воюют сейчас армии девелоперов пытаясь перевести их куда-то еще.

Люди как были людьми так ими и остались. Я бы даже сказал что те кто на МФ были поумнее были. Я видел много прекрасных приложений на МФ, и уверен что удачные переводы с МФ в конце 90-х, начале и продолжении 2000-х именно потому и удачные были что на МФ их толковые люди толково имплементировали.
Далеко за примером ходить не надо. Мы в прошлом году перевели с МФ приложение написанное на CICS/Cobol, DB2 и CICS на Оракл/Java. Переписывал вендор (baseline) и наши программисты (customization), используя вендорский тулз.

[zVlad]

Для успеха перевода приложений с мэйнфрэймов нужно, в первую очередь, иметь достаточное количество заинтересованных в переводе, хороших специалистов по мэйнфрэйм.
Не кого-нибудь кто когда-то что-то делал на мэйнфрэйм, а постоянно работающих на МФ, знающих МФ, и заинтересованных в теме.

Может, у вас, в Торонто оно и так.
А у нас, в столице, как и в марксизме, нужны все три составные части:
1. Высшие гос-манагеры, которые неслабые финансы одобрят из вечно-урезаемого госбюджета.
2. Среднего уровня гос-манагеры - которым захотелось карьеру сделать на разработке новизны из старины.
3. И команда реальных разработчиков-контракторов, которые лыко вяжут и фишку рубят. Впрочем, таковых давно я не видал.

Что Вы заладили "у нас в столице, ... у нас в столице... у вас в Торонто". Все везде одинаково нынче. Все прикормлены и надрессированы либо Оракл-ом, либо Гуглом либо Микрософтом либо еще кем то помельче.
По большому счету все они предлагают одно и тоже только с разными названиями и прайс листами.
1. Высшие менеджеры (не только гос-) передали клюшку помощнику и ударили по рукам с менеджерами из либо одного из крупняков перечисленных выше либо кого помельче.
2. Среднее звено менеджеров на сегодня полностью лишено опыта какой-либо осознанной деятельности в ИТ и полностью отдает решение проблем "специалистам".
3. Команды набираются под то о чем договорились в пункте 1 выше. Эти команды состоят из уже обученных крупняком "специалистов", которые "знают что надо лелать".

Главное - набрать правильную команду.
На местах тоже идут процессы перековывание домашних лошадей подковами выбранного "крупняка".
Мне, например, прилаживают подковы Docker's, Kubernetis, Linux, Azure. Все то что нынче продвигает Microsoft.

[zVlad]

...
КМК никакие манагеры, никакие деньги не заменят главной составной части: детального знания того что приложение делает и что оно должно делать.
Неведение сего и есть главный двигатель КОБОЛизации систем.
"...и вдруг нам становится страшно что-то менять"

Вернемся к Коболу. В моем длинном спиче выше я пытался показать что дело не в том на чем написано, и даже не в том как, а что написано, и о чем написано.
Любая бизнес задача должна проходить переработку в термины и принципы средств ИТ. Это стало понятно давно уже. В результате родилась специализация "бизнес аналитик". Т.е. как бы и ит-шник и как бы и знаток бизнеса.
Раньше это происходило, или не происходило, естественным путем. Как правило ит-шник погружался, или не погружался, в бизнес. В результате получались, или не получались, хорошие, плохие, приложения. Я знаю одно исключение когда человек образованный (университетом - экономика, МBA) быть в бизнесе сам освоил программирование, сохранил свои позиции на бизнес уровне и сейчас у него довольно хорошо получается
Сейчас этому учат. В результате получается как правило не то ни се. Опыта нет, знания, и в том и другом, так себе..

Ну и повторюсь. Сейчас есть туча приложений не на МФ, которые с огромным трудом тащат вперед обливаясь потом только потому что они могут выполнять только на старом железе и в старых версиях систем.
В случае с МФ в этом смысле ситуация другая. Все приложения написанные с момента появления самых первых железок и самых первых версий ОС вплоть до анонсированного в прошлом году 16-го поколения железа и хрен знает какой версии ОС (она переименовывалась и нумерация начиналась снова).
Более того все новое (или просто популярное, как, например, ТСР, С, С++, Java, etc..) на уровне сервера на МФ тоже адаптировалось и имеется. Linux, например.
За такую платформу как МФ, по умному, надо держаться обеими руками и ногами.

Но "мы же умнее всех".

[Плюшка]

Для успеха перевода приложений с мэйнфрэймов нужно, в первую очередь, иметь достаточное количество заинтересованных в переводе, хороших специалистов по мэйнфрэйм.
Не кого-нибудь кто когда-то что-то делал на мэйнфрэйм, а постоянно работающих на МФ, знающих МФ, и заинтересованных в теме.

Может, у вас, в Торонто оно и так.
А у нас, в столице, как и в марксизме, нужны все три составные части:
1. Высшие гос-манагеры, которые неслабые финансы одобрят из вечно-урезаемого госбюджета.
2. Среднего уровня гос-манагеры - которым захотелось карьеру сделать на разработке новизны из старины.
3. И команда реальных разработчиков-контракторов, которые лыко вяжут и фишку рубят. Впрочем, таковых давно я не видал.

Что Вы заладили "у нас в столице, ... у нас в столице... у вас в Торонто". Все везде одинаково нынче. Все прикормлены и надрессированы либо Оракл-ом, либо Гуглом либо Микрософтом либо еще кем то помельче.
По большому счету все они предлагают одно и тоже только с разными названиями и прайс листами.
1. Высшие менеджеры (не только гос-) передали клюшку помощнику и ударили по рукам с менеджерами из либо одного из крупняков перечисленных выше либо кого помельче.
2. Среднее звено менеджеров на сегодня полностью лишено опыта какой-либо осознанной деятельности в ИТ и полностью отдает решение проблем "специалистам".
3. Команды набираются под то о чем договорились в пункте 1 выше. Эти команды состоят из уже обученных крупняком "специалистов", которые "знают что надо лелать".

Главное - набрать правильную команду.
На местах тоже идут процессы перековывание домашних лошадей подковами выбранного "крупняка".
Мне, например, прилаживают подковы Docker's, Kubernetis, Linux, Azure. Все то что нынче продвигает Microsoft.

Это подтверждает что в столице у госслужб - совсем не так как в Торонто. Здесь договорняки идут с крупными конторами. Типа КПМГ. Или с небольшими здешними у которых есть какбы особая связь с манагерами. А затем исполнитель уже приводит (точнее набирает из незнамо кого) ораву какбы спецов. "Правильных командЭ за последние двадцать лет не видел не одной. "Бригад ух" - немало.