ERP и 1й закон кибернетики

[ax_mct]

Цитата:

Сообщение от EVGL

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

Победить сложность можно только декомпозицией. Потенциально если стандартизировать интерфейсы как это делается для EDI то вполне может быть "easily exchanged".

[ax_mct]

Цитата:

Сообщение от Pavel

Это такой стёб, да? Gartner&Carol Hardcastle тоже ссылаются на 1-й закон Кибернетики?

Довольно много в англоязычных публикациях и книгах про ERP отсылок на 1-й закон Кибернетики в контексте требуемой клиентами гибкости. Прежде чем начинать тему я их немного почитал.

Google "The Law of Requisite Variety and ERP".

[DynamicsDevCons@yandex.ru]

Цитата:

Сообщение от ax_mct

Победить сложность можно только декомпозицией.

Почему декомпозиция это победа над сложностью?

[ax_mct]

Цитата:

Сообщение от DynamicsDevCons@yandex.ru

Почему декомпозиция это победа над сложностью?

Потому что научный метод разделения сложного на простые части.
https://ru.wikipedia.org/wiki/%D0%94...86%D0%B8%D1%8F

Взаимодействие этих простых частей имеет свою цену но другого инженерная мысль не знает. Модуль это то что можно отсоединить и присоединить.

Софт должен следовать законам как инженерным там и кибернетики.
ООП и жесткая централизация далеки от этих законов поэтому и приходим к тому к чему пришли.

[skuull]

Цитата:

Сообщение от ax_mct

Потому что научный метод разделения сложного на простые части.
https://ru.wikipedia.org/wiki/%D0%94...86%D0%B8%D1%8F

Взаимодействие этих простых частей имеет свою цену но другого инженерная мысль не знает. Модуль это то что можно отсоединить и присоединить.

Софт должен следовать законам как инженерным там и кибернетики.
ООП и жесткая централизация далеки от этих законов поэтому и приходим к тому к чему пришли.

Ну некоторые пришли к микросервисам

[ax_mct]

Цитата:

Сообщение от skuull

Ну некоторые пришли к микросервисам

Ага, я помню

Цитата:

Пока весь мир вокруг уменьшает coupling, придумывает всякие микросервисы и прочей дурью маються мы 20 с лишним лет валим все в один неймспейс и тычим пальцем в дураков которые создают больше одной модели.

Думаю да, если без деления до атомов, то оно и есть. Похоже что концепция микро-сервисов ближе к кибернетике чем монолит. Но для ERP уровня мне кажется что сервисы уровня модуля будут практичнее, а внутри модуля микро уровень по необходимости. Иначе с тысячами микро-сервисов будут с ностальгией вспоминать монолит

Определение "микро" довольно интересное есть в хорошей статье про микро-сервисы https://habrahabr.ru/post/249183/

Цитата:

наиболее популярным сейчас считается мнение о том, что сервис должен быть настолько большим, чтобы он мог полностью «уместиться в голове разработчика», независимо от количества строк кода

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

[ax_mct]

Интересно что согласно статье концепция ESB и концепция микро-сервисов не дружат.
Умный канал и глупый канал. Что лучше для 1 закона? По моему микро, но они слишком микро.

Цитата:

При выстраивании коммуникаций между процессами мы много раз были свидетелями того, как в механизмы передачи данных помещалась существенная часть логики. Хорошим примером здесь является Enterprise Service Bus (ESB). ESB-продукты часто включают в себя изощренные возможности по передаче, оркестровке и трансформации сообщений, а также применению бизнес-правил.

Комьюнити микросервисов предпочитает альтернативный подход: умные приемники сообщений и глупые каналы передачи. Приложения, построенные с использованием микросервисной архитектуры, стремятся быть настолько незавимыми (decoupled) и сфокусировнными (cohesive), насколько возможно: они содержат собственную доменную логику и выступают больше в качестве фильтров в классическом Unix-овом смысле — получают запросы, применяют логику и отправляют ответ. Вместо сложных протоколов, таких как WS-* или BPEL, они используют простые REST-овые протоколы.

https://habrahabr.ru/post/249183/

[Pavel]

Цитата:

Сообщение от ax_mct

Софт должен следовать законам как инженерным там и кибернетики.
ООП и жесткая централизация далеки от этих законов поэтому и приходим к тому к чему пришли.

Это все иллюзии... миром правит экономика и учет затрат. Сто лет назад индустриальный мир 'держался' на угле, нефть перерабатывали, чтобы получить керосин (как источник топлива), а бензин выливали в реки (пока не распространились автомобили с двигателем внутреннего сгорания). Уголь и сейчас самый распространенный источник энергии, потому что он САМЫЙ ДЕШЕВЫЙ.

Можно сколько угодно грезить 'новыми технологиями', но ни одна из них не распространится, пока 'старая' дешевле и эффективней.
Есть масса примеров, когда 'перспективные технологии' уходили в небытие, так и не став 'массовым' продуктом.

[skuull]

Цитата:

Сообщение от Pavel

Это все иллюзии... миром правит экономика и учет затрат. Сто лет назад индустриальный мир 'держался' на угле, нефть перерабатывали, чтобы получить керосин (как источник топлива), а бензин выливали в реки (пока не распространились автомобили с двигателем внутреннего сгорания). Уголь и сейчас самый распространенный источник энергии, потому что он САМЫЙ ДЕШЕВЫЙ.

Можно сколько угодно грезить 'новыми технологиями', но ни одна из них не распространится, пока 'старая' дешевле и эффективней.
Есть масса примеров, когда 'перспективные технологии' уходили в небытие, так и не став 'массовым' продуктом.

Я конечно понимаю, что это экспертное мнение, но есть примеры из мира более близкого нам - программирования ?

[ax_mct]

Цитата:

Сообщение от Pavel

Можно сколько угодно грезить 'новыми технологиями', но ни одна из них не распространится, пока 'старая' дешевле и эффективней.
Есть масса примеров, когда 'перспективные технологии' уходили в небытие, так и не став 'массовым' продуктом.

То есть PHP forever

А в контексте ERP осознание того что ERP это дорого и неэффективно все более и более становится распространненым мнением. По сути очевидным и массовым.

И что хочет бизнес? Бизнес хочет 1й закон кибернетики во втором его решении, чтобы гибкость самой системы соответствовала изменчивости бизнеса.

Вместо монолита предлагаются облака, которые продолжают быть несовместимы с 1й законом кибернетики. Знаешь кибернетику - видишь будущее

[Pavel]

Цитата:

Сообщение от skuull

Я конечно понимаю, что это экспертное мнение, но есть примеры из мира более близкого нам - программирования ?

Вопрос представляется мне удивительным, ведь пример тут у всех перед глазами... как дешевое и массовое решение безжалостно покончило с 'грандиозными планами&перспективами' [продуктами] одного очень известного вендора. Экономика рулит, пока кто-то витает в облаках, тратит бабло на все новые сочинения сказок.

[Pavel]

Цитата:

Сообщение от ax_mct

То есть PHP forever

А в контексте ERP осознание того что ERP это дорого и неэффективно все более и более становится распространненым мнением. По сути очевидным и массовым.

И что хочет бизнес? Бизнес хочет 1й закон кибернетики во втором его решении, чтобы гибкость самой системы соответствовала изменчивости бизнеса.

Вместо монолита предлагаются облака, которые продолжают быть несовместимы с 1й законом кибернетики. Знаешь кибернетику - видишь будущее

Полагаю, это не имеет никакого отношения собственно к бизнесу. Клиенты останутся клиентами, заказы - заказами... процессы - процессами, а косяки кастомизации - косяками)))

[ax_mct]

Цитата:

Сообщение от Pavel

Полагаю, это не имеет никакого отношения собственно к бизнесу. Клиенты останутся клиентами, заказы - заказами... процессы - процессами, а косяки кастомизации - косяками)))

Бизнес действительно не парится. Чего ему парится, он же бизнес (c).

Но при неэффективности инструментов и технологий остается "гибкость самой системы соответствовала изменчивости бизнеса" ("Variety absorbs variety" ).
Как результат
Next without Noobs...

Цитата:

Осталось место только для реальных гладиаторов! Вот она истинная смена эпохи! Я думал что такое происходит только с аксаптой, но по факту так сейчас по всей ИТ отрасли. Сдохни, но сделай! "Железо" не терпит нежного подхода...

Компенсация приходится на специалистов ERP. Это они танцуют в variety.

[skuull]

Цитата:

Сообщение от Pavel

Вопрос представляется мне удивительным, ведь пример тут у всех перед глазами... как дешевое и массовое решение безжалостно покончило с 'грандиозными планами&перспективами' [продуктами] одного очень известного вендора. Экономика рулит, пока кто-то витает в облаках, тратит бабло на все новые сочинения сказок.

Кто покончил ? С кем покончил ? Где покончил ?

[fed]

Цитата:

Сообщение от skuull

Кто покончил ? С кем покончил ? Где покончил ?

Вероятно, речь идет о доминировании в РФ программного обеспечения 1С и схлопования рынка Dynamics Nav/Ax. В Турции, к слову сказать, картина достаточно похожа, только вместо единственного 1с в mid-market сегментах борятся две или три локальных системы. А число аксаптовских проектов упало с где-то 20 новых проектов в год (эдак году в 2014) до 2-3 (в прошедшем финансовом году).

[Ace of Database]

В программировании опять наступила сингулярность (как это было до появления .NET в начале 21 века, когда опять начался хаос).
А теперь сингулярность - это 1С. Программисты 1С даже не умеют печатать на клавиатуре по-английски. В 1С пользуются всего одним инструментом - построителем запросов. Читают книжки с картинками, и внедряют.
Кстати, лучшие версии Аксапты сформировались в эпоху первой сингулярности в программировании - до появления .NET

[DynamicsDevCons@yandex.ru]

Цитата:

Сообщение от Ace of Database

А теперь сингулярность - это 1С.

Продажи по DAX падают во всем мире. Может дело не в 1С? Кстати, не заметил, чтобы специалисты 1С жаловались на жизнь. Может проблема и не в затухании рынка ЕРП в виду первого закона кибернетики? А виновата вполне конкретная компания испоганившая превосходный продукт.

[EVGL]

Цитата:

Сообщение от ax_mct

Потенциально если стандартизировать интерфейсы как это делается для EDI то вполне может быть "easily exchanged".

Вы сталкивались с EDI? Единственный EDI-формат, который был реализован на чтение в AX - это MT940. Работает с ошибками, только в интерактивном режиме (т.е. без автоматизации), и не на полную мощность а так, для галочки. Теперь попробуйте соорудить импорт счета по формату EDI, вот описание: http://www.stylusstudio.com/edifact/D96A/INVOIC.htm, в добрый путь.

До недавнего времени коннектор, который мог бы трансформировать EDIFACT в XML или web-вызов, был только в BizTalk. Теперь EDIFACT реализован в LogicApps, но простым все это не назовешь.

[ax_mct]

Цитата:

Сообщение от EVGL

Вы сталкивались с EDI? Единственный EDI-формат, который был реализован на чтение в AX - это MT940. Работает с ошибками, только в интерактивном режиме (т.е. без автоматизации), и не на полную мощность а так, для галочки. Теперь попробуйте соорудить импорт счета по формату EDI, вот описание: http://www.stylusstudio.com/edifact/D96A/INVOIC.htm, в добрый путь.

До недавнего времени коннектор, который мог бы трансформировать EDIFACT в XML или web-вызов, был только в BizTalk. Теперь EDIFACT реализован в LogicApps, но простым все это не назовешь.

C EDI работал до AX, пожалуй соглашусь что такие стандарты это нечто что не вдохновляет. Но продолжаю думать цена соединения автономных блоков ниже чем уплотнение и растягивание монолита. Понятно что при определенном пороге сложности.

Цитата:

Безусловно, многие практики, используемые в микросервисах, пришли из опыта интеграции сервисов в крупных организациях. Шаблон Tolerant Reader — один из примеров. Другой пример — использование простых протоколов — возник как реакция на централизованные стандарты, сложность которых просто захватывает дух.

https://habrahabr.ru/post/249183/

[ax_mct]

Цитата:

Сообщение от DynamicsDevCons@yandex.ru

Может проблема и не в затухании рынка ЕРП в виду первого закона кибернетики? А виновата вполне конкретная компания испоганившая превосходный продукт.

Хороший пойнт. Но в открытом монолите рано иди поздно предел сложности наступает. Если пихать и распихивать и все это в одном ящике то край наступит рано или поздно.

Или ящик должен быть под замком или таких ящиков должно быть ровно столько чтобы в каждом был порядок. Это и есть Первый закон кибернетики для скажем серванта