Comments 41
1. Чем больше данных, тем более мы ограничены реальным миром (железом). Как пример,
в результате в реальном мире где-то данные хранят строками, где-то колонками, кому-то хватает json-а для передачи данных, кто-то экономит каждый бит и придумывает свои форматы.
2. Чем более гибкая система тем она сложнее и требует более сложных навыков для работы, и чем более гибкой мы будем делать систему, тем больше она будет напоминать обычную бд с SQL (который придумали как простой язык для непрограммистов), а работа аналитика работу программиста.
С ограничениями по железу мы при использовании такого подхода не сталкивались: скажем, ORM или известные "большие платформы" гораздо хуже влияют на производительность.
А в части сложных навыков соглашусь с вами: требования к аналитикам растут, в процессе создания системы приходится гораздо больше думать, чем при привычной разработке. Это ограничение.
Но и подход мы рекомендуем для разработки не всех систем, а только таких, которые работают с очень сложной и изменчивой структурой данных; их создание в любом случае требует больших ресурсов, но при классическом подходе тут есть большие шансы вообще зайти в тупик. Приходилось видеть не одну автоматизированную систему, фактически заброшенную из-за невозможности оперативно вносить в нее требуемые изменения, хотя на разработку были потрачены огромные суммы. В таких случаях построение системы вокруг модели данных однозначно себя оправдывает.
Чем описываемое отличается от dynamics 365/sap или даже ms access?
Прежде всего - отсутствием привязки к конкретной платформе разработки ПО, возможность использовать любые языки и среды программирования.
Кроме того, ни в SAP, ни в Dynamics, ни в Access, насколько мне известно, нет тех возможностей, которые перечислены в статье: мульти-модельное хранение данных, ведение истории/версионность модели и данных (имеется в виду возможность одновременно работать с несколькими версиями модели и данных, а не переключаться между ними), возможность управления моделью данных со стороны программных компонентов, уведомление компонентов об изменении модели данных во время исполнения. Хранение логики исполнения вне кода в перечисленных вами системах в каком-то виде присутствует, но в весьма ограниченном объеме (программирование на встроенном языке нельзя считать переносом логики из кода).
Это как работать с несколькими версиями данных одновременно?
- Это Петя, он же Сережа, он должен нашей компании 150к рублей, или 200к неизвестно чего, так как в этой версии модели мы валюты не прикрутили, в общем как посмотреть.
(про хранить историю я понимаю, но несколько актуальных версий данных… Примерно так же не представляю как несколько одновременных моделей, типа мы ввели новый обязательный реквизит, но те клиенты, что еще не реализовали новую версию модели могут его не заполнять. Это как вообще?)
Пример про несколько версий данных: пусть у нас есть справочник тарифов, с 01.01.2022 тарифы должны измениться. Такое изменение планируется заранее. В системе должны быть программно доступны и старая, и новая версия тарифов. Алгоритмы биллинга должны ночью на 1 января автоматически перейти на расчет по новым тарифам. Поскольку система хранит данные "в 4D", в ней одновременно существуют и старые тарифы, и новые. При запросе к API системы клиент может указать метку времени и получить тарифы, актуальные на это время. Если метку не указать, то вернутся значения, актуальные на текущее время - это обеспечит автоматическое переключение на новые тарифы.
Про историю модели: клиент при работе через API может явно указать, что хочет использовать не текущую версию модели, а версию, актуальную на заданное им время. При этом сами данные одни и те же. В таком случае, да, может возникнуть ситуация, что в одной версии модели какой-то атрибут не обязателен, а в другой обязателен.
Возвращаюсь получив пояснения на уровень выше:
Если понимать мультимодельное хранение данных как разные АПИ для разных клиентов, то это просто разные АРМы для разных ролей — глядя на тот же отпуск табельщик видит только даты, а расчетчик обогащает суммами отпускных — ура, у нас разная модель для разных пользователей.
Ну а регистр курсов валют — это точно присутсвующее в любой учетной системе версионирование данных.
И вообще, 1С — это программа на C, где код максимально отделен от данных. Ну конфигурируется на DSL. В 6.0 довольно примитивном, хватит аналитиков, 7.7 посложнее, но типовые операции может настроить и бухгалтер. 8.3 — ой, мы уже программ не на C, а на BSL. Что думаю в итоге ждет и вашу систему.
Кстати, глядя на 1С Документооборот — все идет на второй круг. А давайте внедрим конструктор бизнес процессов и бизнес событий (и реакций на них), в котором можно обойтись без программиста (ладно, для сложных ситуаций оставим возможность вставок на DSL). И виды документов тоже будем в пользовательском режиме настраивать.
Итог прежний — все, что чуть сложнее линейной обработки заказа делают программисты, но матерясь, что у них отняли IDE. И не стоит называть этих ребят аналитиками. Аналитики заканчиваются в Visio.
Тут, видимо, можно долго спорить о терминологии "программисты"/"аналитики". Также понятно, что хочется обсуждаемое явление свести к тому, что уже известно. Хотя лично я не могу называть программистами людей, которые работают только с редактором онтологии и не написали за свою жизнь ни строчки программного кода.
Я понимаю, что одной статьей сложно убедить всех в том, что то, что толком не получилось у Low code платформ, можно сделать другим способом, не создавая очередного внутриплатформенного языка программирования (онтологическая модель - это не код даже в том смысле, в котором им является язык 1С).
Все, на что я надеюсь - что кто-то из читателей заинтересуется онтологическим моделированием, почитает про него и подумает над тем, как можно применять такие модели в программных продуктах.
Хотя лично я не могу называть программистами людей, которые работают только с редактором онтологии и не написали за свою жизнь ни строчки программного кода.
А как в "редакторе онтологии" задается правило "сумма заказа равна сумме всех его строк + доставка (но если сумма больше X, то доставка бесплатная)"?
Можно описать как SHACL Rule, см. спецификацию https://www.w3.org/TR/shacl-af/
Редактируется с помощью визуального конструктора формул и правил, если он есть в составе платформы, на которой ведется разработка (таких платформ существует несколько), или путем ручного создания элементов онтологии. Можно хоть в Protege создать, при желании - это базовый open source редактор онтологий.
А можете наглядный пример показать?
Потому что я открыл спецификацию по вашей ссылке, и увидел там вот такое (самое близкое к задаче):
ex:RectangleRulesShape
a sh:NodeShape ;
sh:targetClass ex:Rectangle ;
sh:rule [
a sh:TripleRule ;
sh:subject sh:this ;
sh:predicate ex:area ; # Computes the values of the ex:area property at the focus nodes
sh:object [
ex:multiply ( [ sh:path ex:width ] [ sh:path ex:height ] ) ;
] ;
sh:condition ex:RectangleShape ; # Rule only applies to Rectangles that conform to ex:RectangleShape
] .(я даже не буду брать примеры с SPARQL)
Думаю ближайшим аналогом будет код на Прологе, только накликиваемый мышью.
Да, это похожий пример. И пример со SPARQL был бы валиден, у нас для таких есть конструктор.
Приведенная запись - один из вариантов сериализации онтологии. Есть и другие варианты, например в RDF/XML или OWL/XML. Все они при импорте в графовую СУБД дают один и тот же набор триплетов, и при просмотре через редактор выглядят одинаковым образом.
Вы можете зарегистрироваться на https://webprotege.stanford.edu или скачать десктопную версию Protege, загрузить туда этот фрагмент и посмотреть, как он будет выглядеть в редакторе. Увидите иерархию классов, среди которых будут классы NodeShape, RectangleShape, TripleRule и т.д., и индивидуальные объекты этих классов, представляющие конкретное правило.
А теперь давайте рассмотрим следующее изменение требований: доставку могут осуществлять разные перевозчики, для некоторых из них расчет суммы доставки открытый (и, как следствие, должен быть в нашей системе), а для некоторых — закрытый, и делается через вызов поставляемого перевозчиком веб-сервиса. Нужно, чтобы в заказе использовался перевозчик, дающий минимальную стоимость доставки, а финальная стоимость заказа должна считаться с учетом этой стоимости.
Какие действия и кто должен совершить, чтобы реализовать это изменение?
Возможность внести такое изменение только средствами моделирования зависит от того, подумали ли об этом при проектировании системы. Напомню, я не говорил в статье о том, что код полностью заменяется на модель - заменяется в некоторой части.
Если при проектировании подумали о том, что могут существовать перевозчики с закрытым алгоритмом расчета, то в модели должна быть описана сущность "внешний веб-сервис". Здесь уже стандартными спецификациями не обойтись. Для каждого сервиса формально описываются параметры и возвращаемое значение - что-то вроде SHACL Function, только для самого расчета вместо SPARQL-запроса нужно будет делать вызов внешнего сервиса.
К каждому перевозчику в модели привязываем метод расчета стоимости - это может быть SHACL Rule / Function или конкретный "внешний веб-сервис". Алгоритм выбора перевозчика для конкретного заказа, вполне вероятно, останется в коде и будет заключаться в асинхронном запуске расчета стоимости для всех перевозчиков согласно определенным в модели алгоритмам.
Если при проектировании о таком варианте не подумали, значит предстоит рефакторинг кода и модели.
Возможность внести такое изменение только средствами моделирования зависит от того, подумали ли об этом при проектировании системы.
Конечно же, не подумали. Нельзя обо всем подумать заранее.
Алгоритм выбора перевозчика для конкретного заказа, вполне вероятно, останется в коде и будет заключаться в асинхронном запуске расчета стоимости для всех перевозчиков согласно определенным в модели алгоритмам.
… видите, даже вы употребляете слово "алгоритм".
Меня удивляет, если честно, как вы продолжаете называть людей, которые делают такие решения — описания параметров, возвращаемых значений, их преобразование, операции над ними, и все это на машинно-интерпретируемом языке — не программистами. Для меня эта активность — и есть программирование (точнее, "разработка ПО"). Но я уже не первый раз вижу, как ее исполнителей пытаются назвать аналитиками, и никак не могу понять, почему.
Для внесения изменений в автоматизированную систему достаточно создать в онтологической модели описание нового шага процесса, правила перехода к нему, новые типы документов, их возможные связи с объектами других типов, правила отображения в пользовательском интерфейсе.
… ну то есть запрограммировать новый процесс.
Изменения в модель будут вносить не программисты, а аналитики — почти как в Low code платформах, только в более общем/стандартном виде и без привязки к проприетарному решению.
Гм, а как вы проводите разделение между аналитиками и программистами?
В результате реализация, отладка и доставка изменений потребуют меньше времени и ресурсов, чем при классическом подходе.
Это утверждение нуждается в формализуемой проверке.
… ну то есть запрограммировать новый процесс.
Можно запрограммировать (точнее, формально описать в онтологии) новый процесс, можно модифицировать существующий.
Гм, а как вы проводите разделение между аналитиками и программистами?
Это хороший вопрос: в разных компаниях под аналитиками понимают разное. У нас аналитики - это прежде всего те, кто работает с онтологической моделью. Они описывают структуру данных и способы их обработки, часто - в виде формальных правил в онтологии.
Это утверждение нуждается в формализуемой проверке.
Я всего лишь обобщаю наш собственный опыт разработки в соответствии с предложенным подходом. В нашей практике есть конкретные подтверждения: например, когда весной 2020 года вдруг (совершенно неожиданно) началась пандемия, в одной из сопровождаемых нами систем понадобилось обрабатывать новые виды объектов, связанные с ней (тесты, самоизоляцию и т.д.). Благодаря архитектуре системы удалось вывести структуру данных и логику обработки таких объектов в продуктив буквально за пару недель, и затем неоднократно изменять вслед за вводом/отменой различных противоэпидемических мер. Если бы у нас был классический цикл разработки, так быстро мы бы это не сделали.
Можно запрограммировать (точнее, формально описать в онтологии)
Мой пойнт как раз в том, что ваше "формально описать" — это и есть программирование.
Это хороший вопрос: в разных компаниях под аналитиками понимают разное. У нас аналитики — это прежде всего те, кто работает с онтологической моделью. Они описывают структуру данных и способы их обработки, часто — в виде формальных правил в онтологии.
То есть, на самом деле, программисты. Иными словами, ваше противопоставление "изменения в модель будут вносить не программисты, а аналитики" теряет всякий смысл.
Благодаря архитектуре системы удалось вывести структуру данных и логику обработки таких объектов в продуктив буквально за пару недель, и затем неоднократно изменять вслед за вводом/отменой различных противоэпидемических мер. Если бы у нас был классический цикл разработки, так быстро мы бы это не сделали.
Проблема в том, что это ваш опыт. То есть вы выкатываете решения на своей платформе быстрее, чем вы же выкатили бы "в классическом цикле разработки". Это ничего не говорит о том, за сколько бы выкатила другая команда, работающая "в классическом цикле".
Мой пойнт как раз в том, что ваше "формально описать" — это и есть программирование.
Тут, наверное, могут быть разные мнения. Для меня программирование - это написание кода, а манипуляции с элементами онтологической модели - не программирование. Допускаю, что можно считать иначе.
То есть, на самом деле, программисты. Иными словами, ваше противопоставление "изменения в модель будут вносить не программисты, а аналитики" теряет всякий смысл.
Да нет, почему. У нас в компании программисты и аналитики - разные люди с разной квалификацией, я их не путаю) И зарплаты у них разные.
Проблема в том, что это ваш опыт. То есть вы выкатываете решения на своей платформе быстрее, чем вы же выкатили бы "в классическом цикле разработки". Это ничего не говорит о том, за сколько бы выкатила другая команда, работающая "в классическом цикле".
Разумеется, я и не говорю ничего про другие команды. Я привел цикл наблюдений: у нас получилось вот так, а у отдельных других известных мне команд не получилось при другом подходе. Никаких обобщений)
Тут, наверное, могут быть разные мнения. Для меня программирование — это написание кода, а манипуляции с элементами онтологической модели — не программирование.
Написание кода — это кодирование. А программирование — это, гм, способ получить работающую программу.
У нас в компании программисты и аналитики — разные люди с разной квалификацией, я их не путаю
Просто это опять ваша компания и ее специфика.
Разумеется, я и не говорю ничего про другие команды. Я привел цикл наблюдений: у нас получилось вот так, а у отдельных других известных мне команд не получилось при другом подходе.
Вы себе противоречите: сначала "я и не говорю ничего про другие команды", а потом "у других команд не получилось".
Я могу заметить, просто для информации, что я тоже видел случаи, когда команды, у которых модель должны были описывать аналитики без участия программистов (это частое обещание в индустрии), не справлялись там, где традиционная разработка справлялась.
Поэтому я и сказал, что ваше утверждение нуждается в формализуемой проверке — а иначе его ценность для других, гм, сомнительна.
Согласен с @lair по всем пунктам. Доводилось наблюдать, как компания решила разработать гибко конфигурируемое решение, в котором программирование сведено к минимуму, а основную работу делают "аналитики". И тут есть пара подводных камней. Скилсеты хорошего программиста и хорошего аналитика довольно сильно различаются, и в плане грамотной декомпозиции и переиспользования частей кода, ой, т. е. конфигурации, аналитики показывали себя не очень хорошо, примерно на уровне джуниор программистов. Обходясь при этом сильно дороже. Квалифицированные программисты имели тенденцию надолго не задерживаться, т. к. им скучно заниматься "конфигурированием", они хотят программировать. А аналитики постепенно становились "программистами на платформе X" - а такая квалификация не сильно ценится где-то за пределами компании X. Да и на рынке программистов на своей платформе ты не найдешь (если ты не SAP или 1С, условно), а значит, новичков надо обучать с нуля.
Не утверждаю, что описанные проблемы возникают в каждом случае, но мне кажется, они довольно типичны. Есть даже устоявшийся термин Inner Platform Effect.
То, что вы пишете, справедливо для Low code платформ. Выше в обсуждении был вопрос, чем наш подход от них отличается, вот ответ: https://habr.com/ru/post/576304/#comment_23447646
Про квалификацию добавлю, что специальность "онтолог" набирает популярность. Поскольку методы онтологического моделирования описаны спецификациями W3C и позволяют моделировать что угодно, скиллы обучившегося им человека не привязан к платформе, на которой он работает в компании X.
Есть опыт в построении и многолетнем использовании такой системы.
Вкратце на английском, чтоб не запутать в терминологии:
- Data storage: data-driven definition for storage and storage access.
- Backend: data-driven schema, constraints, relations, business logic.
- Frontend: data-driven library of UI controls
- Frontend: data-driven UI to manage the control properties
- Frontend: data-driven support for multiple web and mobile applications
Вобщем, кодовая база минимальна. Остальное - metadata.
В итоге:
- с 2017 несколько коммерческих продуктов - полет нормальный
- планов перехода на классическую разработку нет
- доработка существующих или разработка новых продуктов сократилась на порядок
Детали:
Pros:
надежность выше по сравнению с классической разработкой
нет необходимости "протаскивать" изменение схемы по слоям
по сравнению с ORM (EF и NHibernate), работает шустрее и легче переносится в облако. ORM тенденция генерить массу мелких запросов, которые в облаке при небольшой latency между серверами вызывает серьезные задержки.
хранение в метаданных: схемы приложений (ERD), диаграмм процессов (BPMN), UI, бизнес логики.
мощная система управления правами доступа
идеально для стартапов: позволяет создать MVP и продолжать до полноценного продукта, без переделок.
extremely high "time to market"
Cons:
Порог вхождения выше
Change tracking усложнен т.к. классические VCS (Git) построены на сравнении text data, а в системе сравнивать нужно транзакции (record changes).
Сложно найти разработчиков, на иную модель разработки т.к. переиспользование знаний нулевое и в резюме не напишешь
нет необходимости "протаскивать" изменение схемы по слоям
Это - один из главных моментов, но и в остальном полностью согласен.
Change tracking усложнен т.к. классические VCS (Git) построены на сравнении text data, а в системе сравнивать нужно транзакции (record changes).
Да, добавляется проблема ведения версий модели и - при существенном изменении модели - деплоя модели одновременно с кодом, который готов с ней работать. Особенно печально, если на продуктиве нельзя заменить модель целиком - например потому, что заказчик со своей стороны сам в ней что-то редактирует. Мы к таким операциям приспособились с помощью а) механизма версионирования модели в платформе, б) механизма подписки на изменения в модели - с его помощью можно на сервере разработки формировать лог транзакций, которые меняют модель, и затем применять их на тесте и проде.
Сложно найти разработчиков, на иную модель разработки т.к. переиспользование знаний нулевое и в резюме не напишешь
Мы при найме разработчиков даже ничего не говорим про иную модель) Уже в процессе работы плавно вводим в курс дела.
Можно хранить модели в crdt виде, тогда можно будет мёржить их без конфликта, вычислять дельты и даже находу менять типы. Гляньте проект $hyoo_crowd на эту тему.
extremely high "time to market"
Такое себе преимущество
По просьбе одного из читателей, с кем переписывались в личке, привожу пример алгоритма, работающего с моделью.
Пусть в онтологии описаны некие структурные подразделения или организации, сотрудникам которых доступны некоторые операции с объектами определенных классов (типов) в зависимости от их функциональной роли. В онтологии формализованы правила, каждое из которых представляет собой связку объектов:
[ организация, роль пользователей, класс модели предметной области, операция ]
например:
[ Департамент маркетинга, Ведущий специалист, Клиент, Просмотр ]
[ Департамент маркетинга, Ведущий специалист, Потенциальный клиент, Создание ]
Организационные единицы и классы модели предметной области образуют иерархии, т.е. Департамент маркетинга может содержать вложенные орг. единицы (отделы, группы и т.д.), класс Клиент также может содержать подклассы, например Потенциальный клиент/Активный клиент или Юр. лицо/Физ. лицо.
Пусть пользователь работает со списком клиентов. Системе нужно определить,какие операции он сможет выполнить с каждым из них. Алгоритм будет таким:
1) Построить список всех родителей той орг. единицы, к которой относится пользователь (пройти вверх по иерархии орг. единиц)
2) Построить список всех родителей того класса(-ов), к которому относится проверяемый объект
3) Найти правила, в которых "организация" равна одной из полученных орг. единиц, "класс" равен одному из полученных классов, "роль" равна роли текущего пользователя. Ранжировать правила по степени спецфичности, т.е. правила, определенные для потомков, переопределяют правила, определенные для родителей.
4) По полученному списку правил составить список операций, доступных пользователю.
Подобным образом формализуются и другие правила: перехода процесса между стадиями, видимости свойств объекта разным пользователям, формирования карточки объекта и т.д. При появлении в системе нового класса объектов достаточно создать для него набор правил, и система сможет его обрабатывать.
При появлении в системе нового класса объектов достаточно создать для него набор правил, и система сможет его обрабатывать.
Мне вот интересно, чем это отличается от "при появлении в системе нового класса объектов достаточно создать для него методов/процедур/обработчиков, и система сможет его обрабатывать"?
Все тем же: методы/процедуры/обработчики создаются в программном коде, а правила создаются в онтологической модели. В нашем случае они физически лежат в той же графовой базе (или в других базах, которые на уровне API выглядят как графовая, но это уже детали). Лежат в виде точно таких же триплетов (элементарная единица информации в графовой СУБД), что и описание структуры данных, и сами данные. Технологически все это вместе образует единое и неразрывное структурированное описание знаний об автоматизируемой предметной области, корпоративный граф знаний (см. Enterprise knowledge graph).
Эта технологическая неразрывность означает, что описание правил редактируется теми же инструментами и людьми, что и описание структуры данных, и сами данные (по крайней мере в части справочных данных, с оперативными данными работают пользователи через свои фронт-энды, но и аналитикам они доступны через универсальные инструменты).
Все тем же: методы/процедуры/обработчики создаются в программном коде, а правила создаются в онтологической модели.
Программный код — это программная модель процесса. Вся разница в форме записи?
Эта технологическая неразрывность означает, что описание правил редактируется теми же инструментами и людьми, что и описание структуры данных, и сами данные
Это выглядит удобно, но с одной оговоркой: если для описания правил доступен весь тот же инструментарий, который доступен "обычному программисту" для "традиционного языка программирования" — контроль версий, статический анализ, рефакторинг и так далее.
Как происходит версионироварие и совместная работа над онтологической моделью? Как разделяются условные staging и production версии?
Модель - это набор триплетов в графовой базе данных. Есть транзакции, которые изменяют состояние этой базы. Как и в обычной базе, транзакции можно записать в журнал и получить возможность "бегать" вперед-назад по состояниям базы. Мы с графом работаем не напрямую, а через платформу, которая обеспечивает такую возможность (получить состояние модели на любой момент времени).
Чтобы привести прод в состояние, в котором находится staging, надо применить на нем некий набор транзакций. У нас этот набор формируется автоматически с помощью механизма распространения изменений по подписке через менеджер очередей. То есть в условной очереди Kafka или RabbitMQ копится набор пакетов с транзакциями, и в нужный момент мы перекидываем их в другую очередь, откуда их заберет система на проде и обновит свою модель до очередного состояния.
Совместная работа с моделью происходит через веб-приложение, редактор онтологий. Редактор тоже работает с графом через платформу, соответственно все выполняемые с его помощью действия попадают в журнал транзакций.
Согласен с автором. Давно назрело четкое разделение данных на отдельные слои программного уровня и пользовательских данных. Концепция заложенная в 1981 года Э. Ф. Коддом реляционных БД на основе которой был сформированы стандарты SQL, хорошо подходит для организации данных внутри базы данных и ПО, но не работы с бизнес-данными.
В SAP S/4 HANA и других ERP мы не встретим объекты типа яблочки или машинок, о которых рассказывают в учебниках. Но даже те объекты, которые там есть задают жесткость процессов, которые регулярно приходится «натягивать» на бизнес.
В части комментариев правильно задаются вопросом, зачем для аналитиков отдельный слой со своей онтологией и метамоделью. Ответ в том, что им требуются другие правила и инструменты работы с данными. Пользовательские данные могут содержать ошибки консистентности, выбросы и многое другое. С ними нужно работать и стандарты SQL плохо для этого подходят со своей жесткостью. Что не мыслимо для БД и приведет к краху приложения, может и должно сохраняться в пользовательских данных.
Второе. Как правильно замечено, управление структурой пользовательских данных занимается бизнес. Точнее, управленец с помощью аналитиков. Модель управления регулярно меняется, и программисты столько же в этом понимают, сколько управленец в программирование. Они сами решают какие данные им нужны. По моему мнению, в хороших системах класса АСУ Предприятия (ERP и др.) должна быть возможность изменения модели без изменения функциональности ПО. И не только модели, но и данных после таких изменений.
Существующие технологии пока только определяются и формируются (понятно это не ORM :). В любом случае это тренд, пусть и не все его принимают.
P.S. Из интересных фактов. В amazon и ряде других буржуйских компаний, на балансе предприятия ставят бизнес-данные отдельно от ПО.
Как правильно замечено, управление структурой пользовательских данных занимается бизнес. Точнее, управленец с помощью аналитиков. Модель управления регулярно меняется, и программисты столько же в этом понимают, сколько управленец в программирование. Они сами решают какие данные им нужны.
А вы, я так понимаю, считаете, что управленец и аналитики понимают в проектировании структур данных не хуже программиста?
Из статьи так и не уловил суть. Вы говорите о визуальном программировании или о простом языке для аналитиков? Такие штуки изобретают каждый год и с теми же плюсами как у вас в статье: может разрабатывать аналитик, гибкая архитектура, и т.д Самый цимес состоит в том, что для видов и сложности данных, требуются разные виды хранилищ, алгоритмов и т.д Чёт похоже на маркетинговую агитку.
Как снизить зависимость кода от структуры данных?