Для тех кто проектирует продукты на данных Data Product Canvas [1] нарисованный профессором Leandro Carvalho и доступный всем желающим.
Правда не он первый рисующий подобное. Например, похожий по смыслу и иной по стилю есть от команды Know-Center GmbH, Graz [2] в Австрии.
А если поискать то найдется и ещё. Такие штуки полезны при проектировании продуктов основанных на данных, возможно какие-то даже стоит перевести на русский язык.
Ссылки:
[1]https://medium.com/@leandroscarvalho/data-product-canvas-a-practical-framework-for-building-high-performance-data-products-7a1717f79f0
[2] https://aisel.aisnet.org/bled2020/8/
#itarchitecture #itdesign #data #dataproducts
Правда не он первый рисующий подобное. Например, похожий по смыслу и иной по стилю есть от команды Know-Center GmbH, Graz [2] в Австрии.
А если поискать то найдется и ещё. Такие штуки полезны при проектировании продуктов основанных на данных, возможно какие-то даже стоит перевести на русский язык.
Ссылки:
[1]https://medium.com/@leandroscarvalho/data-product-canvas-a-practical-framework-for-building-high-performance-data-products-7a1717f79f0
[2] https://aisel.aisnet.org/bled2020/8/
#itarchitecture #itdesign #data #dataproducts
Полезная статья о которой хочется написать отдельно Deliver Your Data as a Product, But Not as an Application [1], она требует авторизации на Medium. но почитать её стоит.
Основная идея в том что данные - это продукт, но этот продукт не приложение. Иначе говоря если Ваша бизнес модель построена на предоставлении данных, то надо помнить что именно данные, являются продуктом и не надо смешивать их с кодом.
Собственно в статье отсылка к хорошо известной книге Principles of Data-Oriented Programming [2] и следующим принципам:
- Отделяйте код (поведение) от данных;
- Рассматривайте данные как неизменные (immutable)
- Отделяйте схемы/структуры данных от их представления
- Представляйте данные с помощью простых структур данных
Статья написана с прицелом на OOP разработчиков которые хотели бы понять отличия программирования с данными и без.
Идея отделения данных от кода, в принципе, не нова. Лично я при проектировании разных ИТ продуктов за последние годы придерживался принципа API-first, то есть вначале у тебя появляется API, а потом уже разные интерфейсы поверх него.
В случае с данными оно разделяется на 2+ сервиса API. Первый сервис API для бизнес логики/кода, второй для данных, как правило Data API отдающее JSON или Protocol Buffers. Реальные системы могут иметь больше вариаций по разделению и компонентам, но бизнес логика и доступ к данным разделять стоит всегда.
В этом смысле, если смотреть на продукты статистических служб к примеру, как на дата продукты то сразу в глаза бросается разница где их создатели делают реальный дата продукт, а где приложение для конечного пользователя. Чаще если делают приложение, то результат оказывается гораздо более посредственным чем когда делают доступными данные разными способами.
И это, конечно, относится не только к данным статистики.
Ссылки:
[1] https://towardsdatascience.com/deliver-your-data-as-a-product-but-not-as-an-application-99c4af23c0fb
[2] https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.html
#itarchitecture #datasaproduct #data #api
Основная идея в том что данные - это продукт, но этот продукт не приложение. Иначе говоря если Ваша бизнес модель построена на предоставлении данных, то надо помнить что именно данные, являются продуктом и не надо смешивать их с кодом.
Собственно в статье отсылка к хорошо известной книге Principles of Data-Oriented Programming [2] и следующим принципам:
- Отделяйте код (поведение) от данных;
- Рассматривайте данные как неизменные (immutable)
- Отделяйте схемы/структуры данных от их представления
- Представляйте данные с помощью простых структур данных
Статья написана с прицелом на OOP разработчиков которые хотели бы понять отличия программирования с данными и без.
Идея отделения данных от кода, в принципе, не нова. Лично я при проектировании разных ИТ продуктов за последние годы придерживался принципа API-first, то есть вначале у тебя появляется API, а потом уже разные интерфейсы поверх него.
В случае с данными оно разделяется на 2+ сервиса API. Первый сервис API для бизнес логики/кода, второй для данных, как правило Data API отдающее JSON или Protocol Buffers. Реальные системы могут иметь больше вариаций по разделению и компонентам, но бизнес логика и доступ к данным разделять стоит всегда.
В этом смысле, если смотреть на продукты статистических служб к примеру, как на дата продукты то сразу в глаза бросается разница где их создатели делают реальный дата продукт, а где приложение для конечного пользователя. Чаще если делают приложение, то результат оказывается гораздо более посредственным чем когда делают доступными данные разными способами.
И это, конечно, относится не только к данным статистики.
Ссылки:
[1] https://towardsdatascience.com/deliver-your-data-as-a-product-but-not-as-an-application-99c4af23c0fb
[2] https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.html
#itarchitecture #datasaproduct #data #api