Навик — это MS NAV. Очень существенная доля рынка в Европе среди SMB.
Вообще, начинать статью надо было с этого: «Например 2 первые версии внутреннего языка были забракованы и выкинуты на помойку, потому что в какой-то момент приходило осознание что данный путь в никуда и надо были изначально строить все архитектурно по другому.»
Сразу бы стало понятно — очередное изобретение велосипеда. :)))
И вы не поверите, но ЕРП системы в целом и отчеты в частности — нужны только людям. :)))
«В конфигурируемых системах база данных не как обычно, а имена таблиц и полей состоят из номеров.»
Вот прям таки во всех без исключения? :)))
А статья хорошая — сразу понятен уровень «ERP-Платформы».
А один подрядчик решил написать статью про жадных клиентов, но сам не захотел тратить деньги на проверку статьи. В результате в тексте встречаются замечательные фразы:
«количество чеков в магазине с обученным персоналом в день — 100, в магазине с необученным персоналом — 300.»
:)))
Я думаю, проблема еще и с подбором нужных специалистов.
ИТишников в целом не очень хватает, а хороших специалистов в узкой области вообще очень мало. Особенно если нужен опыт. К 35 — 40 у большинства семья и дети. И работа до 10 вечера не подходит.
То есть проблемой часто является просто подбор нужного специалиста, а если он при этом должен быть белым молодым гетеросексуальным мужчиной без семьи…
Проблема даже не в начальниках отделов, а в директоре и выше. :)))
Сама по себе проблема действительно может возникать, но только при плохом руководстве.
«Оказалось, что что в реализации не была учтена сила обаяния менеджеров по продажам. Ради высоких бонусов они повадились сговариваться с системными администраторами, чтобы те вычищали из логов компромат.»
Ну что тут сказать…
Для «учетных» систем корректная схема данных является критичной. И если при проработке доменной модели мы ошибемся — будут очень большие проблемы.
Я не знаю других способов проверить корректность структуры данных на уровне доменной модели, кроме как попробовать составить логическую схему данных — нормализованную ER диаграмму.
С точки зрения прикладного программиста схема БД, выраженная в конкретных SQL инструкциях для СУБД — это скорее физическая модель, так как на этом уровне часто делают денормализацию. Хотя по классике это, разумеется, логическая модель, а физическую знает только СУБД.
Но удобно разделять «логическую» схему БД — нормализованную ER диаграмму, которая может не содержать многих деталей (типы полей, некоторые поля или вообще не содержать некоторых второстепенных таблиц) и «физическую» схему БД, которая уже «адаптирована» под конкретную СУБД, возможно, частично денормализована и содержит все детали.
Переносить всю логику в БД не получится, да и не очень нужно. Но в «учетных» системах никогда не получается использовать «чистый» ООП, так как критически важно оперировать с данными как множествами. И в результате нарушается инкапсуляция.
Лет эдак 25...30 назад даже UML нотация покрывали эту потребность. С тех пор появились новые нотации, новые приемы и новые инструменты, которые практически на 100% решают такие задачи, вплоть до самовалидации. на этапе рисования.
???
Ваши клиенты хорошо знают UML и новые нотации / инструменты? И с их помощью тот же начальник отдела логистики, например, легко может себе представить алгоритм построения маршрута?
И например все эти команды, которые уже более 10 лет разрабатывают автопилот (всягие гуглы и апплы) — просто не в курсе этих новых инструментов, раз не могут легко представить себе, как именно автопилот должен работать? :)))
На моей памяти, нормально сделанные проекты при соблюдении методологии таких проблем не было. Сдавались с первого раза и шли в работу, как минимум 5 проектов с более чем годовым циклом (для примерной оценки объема)
Другое дело, что можно проверить логическую согласованность вроде требуется артикул номеклатуры в одной сущности, но нету ни в справочниках, ни бизнес правили, ни ограничений, ни участников ответсвенных за эту часть.
Но в процессе приведения доменной модели в адекватное состояние это всплывает.
Это зависит от того как проводится бизнес-анализ, какая нотация какой инструмент.
Создание нормализованной ER диаграммы как раз и является, по моему мнению, хорошим инструментом для поиска неувязок в концептуальной схеме данных и в целом в доменной модели.
Правда, это хорошо работает только при создании «учетных» систем, при создании приложений другого типа этот инструмент не очень полезен.
Я под доменной моделью понимаю некую схему, которая возникает в мозгу архитектора после получения информации от заказчика. И эта схема (которая в мозгу) является исходными данными при формировании архитектуры.
Так вот, очень часто в этой схеме имеются ошибки — или бизнес аналитик и архитектор не так поняли заказчика, или заказчик сам не очень хорошо понимает, как именно должна работать система. Или заказчик просто не упомянул некоторые вещи, которые по его мнению являются не важными или само собой разумеющимися.
Причем ошибки являются правилом, а не исключением.
Самая трудная отдельная задача в разработке программной системы — это точно решить, что разрабатывать. Ни одна другая задача работы над концепциями не является столь трудной, как разработка подробных технических требований, включая все интерфейсы пользователей, машинные интерфейсы и интерфейсы к другим программным системам. Ни одна другая часть работы не наносит такого ущерба готовой системе, если сделана неправильно. Ни одна другая часть не исправляется позднее с бульшим трудом.
Поэтому наиболее важной функцией, осуществляемой разработчиками для своих клиентов, является повторяющееся получение и уточнение требований к продукту. Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумывались над задачей настолько детально, как это нужно указать в спецификации. Даже простой ответ — «сделайте так, чтобы новая программная система работала так, как наша старая ручная система обработки информации» — оказывается в действительности слишком упрощенным. Клиенты никогда не хотят этого в точности. Более того, сложные программные системы действуют, движутся, работают. Динамику этого действия трудно себе представить. Поэтому при планировании любых действий необходимо оставить резерв для многократного взаимодействия между клиентом и проектировщиком при описании системы.
Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют.
Хоть и написано до моего рождения, но в этой области вообще ничего не изменилось. :)))
И если архитектор не проверяет доменную модель на полноту, целостность, согласованность — он сам себе злобный буратино.
Ну так я об этом и говорю — проблема чаще всего в неправильной доменной модели.
Если доменная модель не верна изначально — мы не сможем придумать хорошую архитектуру, и, соответственно, не сможем создать хорошую систему.
И создание логической схемы данных как раз и позволяет найти ошибки в доменной модели.
О чем статья? Создали доменную модель, на её основе выработали архитектуру приложения, но потом обнаружили, что у нас проблемы.
С моей точки зрения, причина этих проблем — неправильная доменная модель, в первую очередь в части концептуальной модели данных. И чтобы избавиться от проблем, надо найти и устранить ошибки / неточности / пробелы в доменной модели.
А как найти ошибки в схеме данных? — попробовать построить нормализованную реляционную схему данных. Теория реляционных БД как раз и разрабатывалась под такие задачи.
Схема данных — это не физика. Это именно логическая модель данных.
Как при создании доменной модели вы проверяете, что в концептуальной модели данных (которая является составной частью доменной модели) нет существеннных ошибок или пробелов, которые в свою очередь могут привести к крупным ошибкам в архитектуре приложения?
:)))
Правильно.
Сначала рисуем доменную модель с Conceptual data model:
A domain model generally uses the vocabulary of the domain so that a representation of the model can be used to communicate with non-technical stakeholders.
А после нам надо проверить — а нет ли каких пробелов в нашей доменной модели / концептуальной схеме данных?
Для этого мы рисуем логическую схему данных в виде нормализованной ER диаграммы.
A logical data model or logical schema is a data model of a specific problem domain expressed independently of a particular database management product or storage technology (physical data model) but in terms of data structures such as relational tables and columns, object-oriented classes, or XML tags. This is as opposed to a conceptual data model, which describes the semantics of an organization without reference to technology
И при построении этой логической модели данных мы как раз и проверяем, нет ли ошибок в концептуальной модели данных.
И если (вернее, когда))) мы находим нестыковки — надо вернуться к доменной модели / концептуальной модели данных, и исправить допущенные ошибки.
Как вообще можно искать ошибки, не пытаясь построить нормализованную ER диаграмму?
А физическая модель — это схема БД, оптимизированная под конкретную СУБД, часто частично денормализованная и т.п.
То, что мы сначала рисуем доменную (концептуальную) модель, не значит, что мы не должны править эту модель после попытки нарисовать логическую структуру данных (нормализованную ER диаграмму).
Именно в торговле запчастями с резервами всё не так просто.
Часто есть понятие торговли «под заказ» — клиент делает заказ, и ему привозят через некоторое время (от поставщика или с другого склада).
Или например кладовщик собирает заказ и видит, что деталь бракованная, и перемещает в зону «брак». И при этом надо что то делать с заказом продажи — ведь теперь товара под него не хватает.
В одном случае, когда система начала не справляться с нагрузкой из-за блокировок, вообще пришлось создавать отдельный «микросервис» для обработки резервов. Вот здесь это обсуждали.
Количество VPN соединений не очень маленькое.
Вообще, начинать статью надо было с этого: «Например 2 первые версии внутреннего языка были забракованы и выкинуты на помойку, потому что в какой-то момент приходило осознание что данный путь в никуда и надо были изначально строить все архитектурно по другому.»
Сразу бы стало понятно — очередное изобретение велосипеда. :)))
И вы не поверите, но ЕРП системы в целом и отчеты в частности — нужны только людям. :)))
Уровень конфигурируемости не скажу что высокий, но много простых задач можно сделать на уровне настроек.
Вот прям таки во всех без исключения? :)))
А статья хорошая — сразу понятен уровень «ERP-Платформы».
«количество чеков в магазине с обученным персоналом в день — 100, в магазине с необученным персоналом — 300.»
:)))
ИТишников в целом не очень хватает, а хороших специалистов в узкой области вообще очень мало. Особенно если нужен опыт. К 35 — 40 у большинства семья и дети. И работа до 10 вечера не подходит.
То есть проблемой часто является просто подбор нужного специалиста, а если он при этом должен быть белым молодым гетеросексуальным мужчиной без семьи…
Сама по себе проблема действительно может возникать, но только при плохом руководстве.
«Оказалось, что что в реализации не была учтена сила обаяния менеджеров по продажам. Ради высоких бонусов они повадились сговариваться с системными администраторами, чтобы те вычищали из логов компромат.»
Ну что тут сказать…
Я не знаю других способов проверить корректность структуры данных на уровне доменной модели, кроме как попробовать составить логическую схему данных — нормализованную ER диаграмму.
Но удобно разделять «логическую» схему БД — нормализованную ER диаграмму, которая может не содержать многих деталей (типы полей, некоторые поля или вообще не содержать некоторых второстепенных таблиц) и «физическую» схему БД, которая уже «адаптирована» под конкретную СУБД, возможно, частично денормализована и содержит все детали.
Ведь у меня и всех моих знакомых такие проблемы были…
Иногда больше, иногда меньше — но на всех проектах.
???
Ваши клиенты хорошо знают UML и новые нотации / инструменты? И с их помощью тот же начальник отдела логистики, например, легко может себе представить алгоритм построения маршрута?
И например все эти команды, которые уже более 10 лет разрабатывают автопилот (всягие гуглы и апплы) — просто не в курсе этих новых инструментов, раз не могут легко представить себе, как именно автопилот должен работать? :)))
Какой методологии? Водопада?
Создание нормализованной ER диаграммы как раз и является, по моему мнению, хорошим инструментом для поиска неувязок в концептуальной схеме данных и в целом в доменной модели.
Правда, это хорошо работает только при создании «учетных» систем, при создании приложений другого типа этот инструмент не очень полезен.
Так вот, очень часто в этой схеме имеются ошибки — или бизнес аналитик и архитектор не так поняли заказчика, или заказчик сам не очень хорошо понимает, как именно должна работать система. Или заказчик просто не упомянул некоторые вещи, которые по его мнению являются не важными или само собой разумеющимися.
Причем ошибки являются правилом, а не исключением.
Хоть и написано до моего рождения, но в этой области вообще ничего не изменилось. :)))
И если архитектор не проверяет доменную модель на полноту, целостность, согласованность — он сам себе злобный буратино.
Если доменная модель не верна изначально — мы не сможем придумать хорошую архитектуру, и, соответственно, не сможем создать хорошую систему.
И создание логической схемы данных как раз и позволяет найти ошибки в доменной модели.
О чем статья? Создали доменную модель, на её основе выработали архитектуру приложения, но потом обнаружили, что у нас проблемы.
С моей точки зрения, причина этих проблем — неправильная доменная модель, в первую очередь в части концептуальной модели данных. И чтобы избавиться от проблем, надо найти и устранить ошибки / неточности / пробелы в доменной модели.
А как найти ошибки в схеме данных? — попробовать построить нормализованную реляционную схему данных. Теория реляционных БД как раз и разрабатывалась под такие задачи.
Схема данных — это не физика. Это именно логическая модель данных.
А по поводу топика и двухфазного коммита — в обсуждении под распределенными базами подразумевается решение 1С:
Механизмы обмена данными позволяют создавать территориально распределенные информационные системы обменивающиеся данным в офф-лайн режиме, без постоянного соединения.
Правильно.
Сначала рисуем доменную модель с Conceptual data model:
А после нам надо проверить — а нет ли каких пробелов в нашей доменной модели / концептуальной схеме данных?
Для этого мы рисуем логическую схему данных в виде нормализованной ER диаграммы.
И при построении этой логической модели данных мы как раз и проверяем, нет ли ошибок в концептуальной модели данных.
И если (вернее, когда))) мы находим нестыковки — надо вернуться к доменной модели / концептуальной модели данных, и исправить допущенные ошибки.
Как вообще можно искать ошибки, не пытаясь построить нормализованную ER диаграмму?
А физическая модель — это схема БД, оптимизированная под конкретную СУБД, часто частично денормализованная и т.п.
То, что мы сначала рисуем доменную (концептуальную) модель, не значит, что мы не должны править эту модель после попытки нарисовать логическую структуру данных (нормализованную ER диаграмму).
Часто есть понятие торговли «под заказ» — клиент делает заказ, и ему привозят через некоторое время (от поставщика или с другого склада).
Или например кладовщик собирает заказ и видит, что деталь бракованная, и перемещает в зону «брак». И при этом надо что то делать с заказом продажи — ведь теперь товара под него не хватает.
В одном случае, когда система начала не справляться с нагрузкой из-за блокировок, вообще пришлось создавать отдельный «микросервис» для обработки резервов. Вот здесь это обсуждали.