VU
Мое мнение на мидлвейре, для центричного управления входящими структурами и разгрузки конечных систем от чуждого им функционала
Size: a a a
2020 August 24
VU
мидлвейр бизнес-агностик, но и трансформация не имеет ничего общего с бизнесом и ориентирована на системы
A
Вообще трансформатор выделяется как отдельный сервис, по сути он тоже мидловый
Вы под конечными системами понимаете локальные продукты с отчетами что ли? Тогда конечно, трансформация должна проходить до них. Я думал, потребляющие системы - это верхнеуровневая СППР для менеджмента
Вы под конечными системами понимаете локальные продукты с отчетами что ли? Тогда конечно, трансформация должна проходить до них. Я думал, потребляющие системы - это верхнеуровневая СППР для менеджмента
A
мидлвейр бизнес-агностик, но и трансформация не имеет ничего общего с бизнесом и ориентирована на системы
Вот считаю, что как раз имеет. Недавно пришел к вывооду, что это перевод с языка одних стейкхолдеров на язык других. Поэтому у нее по сути в основе лежит чисто бизнесовый смысл
VU
Andrey
Вообще трансформатор выделяется как отдельный сервис, по сути он тоже мидловый
Вы под конечными системами понимаете локальные продукты с отчетами что ли? Тогда конечно, трансформация должна проходить до них. Я думал, потребляющие системы - это верхнеуровневая СППР для менеджмента
Вы под конечными системами понимаете локальные продукты с отчетами что ли? Тогда конечно, трансформация должна проходить до них. Я думал, потребляющие системы - это верхнеуровневая СППР для менеджмента
Конечные системы покрывают бизнес-процессы в соответствующих частях
VU
Andrey
Вот считаю, что как раз имеет. Недавно пришел к вывооду, что это перевод с языка одних стейкхолдеров на язык других. Поэтому у нее по сути в основе лежит чисто бизнесовый смысл
Данные не изменяются, изменяется структура
A
Данные не изменяются, изменяется структура
Ну и что
VU
Пример простой (гипотетический), во внешней системе принято записывать ФИО в одном поле, в конечно в трёх, где должна быть трансформация структуры? Если в конечной, то это заставляет её знать источник данных, систему, что ведёт к сильной связанности
A
Пример простой (гипотетический), во внешней системе принято записывать ФИО в одном поле, в конечно в трёх, где должна быть трансформация структуры? Если в конечной, то это заставляет её знать источник данных, систему, что ведёт к сильной связанности
Да это не принципиальный вопрос. Вы по сути ставите вопрос - где должен находиться сервис трансформации, внутри приемника или вне его. Какая разница.
VU
Andrey
Да это не принципиальный вопрос. Вы по сути ставите вопрос - где должен находиться сервис трансформации, внутри приемника или вне его. Какая разница.
Это пример
VU
Пример простой (гипотетический), во внешней системе принято записывать ФИО в одном поле, в конечно в трёх, где должна быть трансформация структуры? Если в конечной, то это заставляет её знать источник данных, систему, что ведёт к сильной связанности
Если источников много, то конечному приемнику необходимо учитывать нюансы всех, даже если данные одинаковые, а различается лишь формат
VU
(Маловероятный кейс, но) Плюс другие системы обязаны дублировать функционал трансформации, если им необходимы те же данные от тех же источников (формат конечный для всего ландшафта сейчас есть возможность определить)
A
Вот Oracle дает одну отдельную систему трансформации на всю архитектуру (Oracle Data Integrator, кажется).
Но они сейчас пропогандируют механику ELT. То есть эта система забирает данные из источника, кладет их в приемник, а уже после этого трансформирует. Гибридный вариант получается.
Но они сейчас пропогандируют механику ELT. То есть эта система забирает данные из источника, кладет их в приемник, а уже после этого трансформирует. Гибридный вариант получается.
VU
Поясню, я не про ETL, взаимодействие посредством API (сервисы/сообщения)
VU
Andrey
Вообще трансформатор выделяется как отдельный сервис, по сути он тоже мидловый
Вы под конечными системами понимаете локальные продукты с отчетами что ли? Тогда конечно, трансформация должна проходить до них. Я думал, потребляющие системы - это верхнеуровневая СППР для менеджмента
Вы под конечными системами понимаете локальные продукты с отчетами что ли? Тогда конечно, трансформация должна проходить до них. Я думал, потребляющие системы - это верхнеуровневая СППР для менеджмента
Конечные системы не просто агрегаторы данных, данные используются в работе систем
A
(Маловероятный кейс, но) Плюс другие системы обязаны дублировать функционал трансформации, если им необходимы те же данные от тех же источников (формат конечный для всего ландшафта сейчас есть возможность определить)
Вот поэтому и делается индивидуальный выбор: если данные (точнее, структура, как Вы говорите) специфичны для одной системы - можно выполнять трансформацию в ней.
Если используются для нескольких систем - лучше вынести, или выстроить data flow так, чтобы зависимые системы забирали из этой.
Если используются для нескольких систем - лучше вынести, или выстроить data flow так, чтобы зависимые системы забирали из этой.
VU
Andrey
Вот поэтому и делается индивидуальный выбор: если данные (точнее, структура, как Вы говорите) специфичны для одной системы - можно выполнять трансформацию в ней.
Если используются для нескольких систем - лучше вынести, или выстроить data flow так, чтобы зависимые системы забирали из этой.
Если используются для нескольких систем - лучше вынести, или выстроить data flow так, чтобы зависимые системы забирали из этой.
А аргументы?
AS
здравый смысл
2020 August 25
GK
- Нужно различать взамодействие и интеграцию
- Если речь идёт о взаимодействии, то потребители должны адаптироваться к поставщику, то есть трансформация должна выполняться в адаптерах потребителей
- Если речь идёт об интеграции (минимум двух компонентов/сервисов/систем), то трансформация должны выполняться в мидле/посреднике
- Если речь идёт о взаимодействии, то потребители должны адаптироваться к поставщику, то есть трансформация должна выполняться в адаптерах потребителей
- Если речь идёт об интеграции (минимум двух компонентов/сервисов/систем), то трансформация должны выполняться в мидле/посреднике
VU
- Нужно различать взамодействие и интеграцию
- Если речь идёт о взаимодействии, то потребители должны адаптироваться к поставщику, то есть трансформация должна выполняться в адаптерах потребителей
- Если речь идёт об интеграции (минимум двух компонентов/сервисов/систем), то трансформация должны выполняться в мидле/посреднике
- Если речь идёт о взаимодействии, то потребители должны адаптироваться к поставщику, то есть трансформация должна выполняться в адаптерах потребителей
- Если речь идёт об интеграции (минимум двух компонентов/сервисов/систем), то трансформация должны выполняться в мидле/посреднике
Аргументы?