Методичка, конечно, есть. Классификация давно придумана.
Но вы можете попробовать сделать это сами, помощниками у вас могут стать референсные модели данных. Подобная модель точно есть у ритейла, банков, телекома.
Пользуются ли в банках этими моделями? Да, пользуются. У всех ли банков одинаковый реестр данных? Нет, он разный у всех.
Из практического опыта: в большинстве компаний в качестве классификатора данных выступает модель хранилища. Насколько это эффективно - судить владельцам этих хранилищ. Насколько такой подход "юзабилити" для всех остальных пользователей компании? Остаётся вопросом, ограничения очевидны.
Тем не менее, Банк России регулярно выпускает рекомендации к управлению данными. Думаю, что в скором будущем мы увидим единый для всех участников финансового рынка реестр данных.
Архитектура данных - всё же более точное определение для артефакта, стстематизирующего ваши данные.
Когда мы говорим про реестр данных Банка (или любой другой организации) - это значит, что нам нужно решить задачу Систематизации и классификации данных. Это задача находится, обычно, в зоне ответственности Архитектуры данных или Информационной архитектуры (см.в статье).
С другой стороны, когда мы составляем реестр данных, нужно понимать какие цели мы преследуем. В случае с регулятором ЦБ это будет удовлетворение требованиям 716-П.
Пошагово ваши действия следующие: 1. Выделить бизнес-критичные области данных, они находятся внутри критических бизнес-процессов, обеспечивающих непрерывность деятельности банка. 2. Определить ответственных за качество данных внутри этих процессов - назначить Владельцев данных (обычно это владельцы процессов или бизнес-эксперты). 3. Владельцы данных должны обозначить критичные данные и описать требования к их качеству. 4. Чтобы избежать дублирования или разночтения между отдельными предметными областями, информационный архитектор должен структурировать все описанные данные и разложить их в модель - обычно, это корпоративная модель данных.
Так что одни архитекторы тут не справятся, потребуются дата-стюарды для обеспечения процесса сбора описаний к данным и активное вовлечение бизнеса. Потом займётесь не критичными данными))
А вообще, приходите ко мне в телеграмм-канал, там много инфо вот про это всё (в профиле есть ссылка).
Все штуки у всех так или иначе из книжек. Я всегда всем не перестаю повторять - берите любую заумную модель и пробуйте натянуть ее на себя, если взлетит - повезло, если нет - не ваше или носить не умеете )))
К чему я - нет смысла всё прикладывать к себе один к одному, нужно уметь адаптировать хорошие вещи под свои кейсы. Копните поглубже сами, прежде чем чужой столетний опыт подвергать сомнениям ))
Мне кажется, что иногда не нужно пытаться объять необъятное - вселенная непредсказуема, а время быстротечно. Как бы мы ни гнались за модой, она изменится.
Я лишь пытаюсь здесь и сейчас использовать предложенную Захманом модель для нужд моделирования данных, и неплохо получается. Но, конечно, не поручусь, что спустя сотню лет эти же знания будут востребованы и применимы как прежде.
Прошу простить меня за невежество и позвольте пригласить в свой канал - @DataGovernance4all , где с удовольствием подискутирую с вами и выслушаю прочую критику к моим постам.
Именно поэтому Время фиксируется некими событийными фактами - или в прошлом или в будущем.
Конечно, мы не можем "поймать время за хвост", но описать будущие или свершившиеся факты через статусные или событийные модели - вполне себе в состоянии.
Что же вам всё таки смущает? Тот факт, что мы каким-то образом пытаемся зафиксировать или смоделировать время?
Event - это как раз про время, оставила классическое название от Захмана. В работе - да, там везде Time использую для очевидности. Если на сам Фреймворк посмотреть, то видно, что рядом с Event стоит вопрос "когда?"
Методичка, конечно, есть. Классификация давно придумана.
Но вы можете попробовать сделать это сами, помощниками у вас могут стать референсные модели данных. Подобная модель точно есть у ритейла, банков, телекома.
Пользуются ли в банках этими моделями? Да, пользуются. У всех ли банков одинаковый реестр данных? Нет, он разный у всех.
Из практического опыта: в большинстве компаний в качестве классификатора данных выступает модель хранилища. Насколько это эффективно - судить владельцам этих хранилищ. Насколько такой подход "юзабилити" для всех остальных пользователей компании? Остаётся вопросом, ограничения очевидны.
Тем не менее, Банк России регулярно выпускает рекомендации к управлению данными. Думаю, что в скором будущем мы увидим единый для всех участников финансового рынка реестр данных.
Архитектура данных - всё же более точное определение для артефакта, стстематизирующего ваши данные.
Когда мы говорим про реестр данных Банка (или любой другой организации) - это значит, что нам нужно решить задачу Систематизации и классификации данных. Это задача находится, обычно, в зоне ответственности Архитектуры данных или Информационной архитектуры (см.в статье).
С другой стороны, когда мы составляем реестр данных, нужно понимать какие цели мы преследуем. В случае с регулятором ЦБ это будет удовлетворение требованиям 716-П.
Пошагово ваши действия следующие:
1. Выделить бизнес-критичные области данных, они находятся внутри критических бизнес-процессов, обеспечивающих непрерывность деятельности банка.
2. Определить ответственных за качество данных внутри этих процессов - назначить Владельцев данных (обычно это владельцы процессов или бизнес-эксперты).
3. Владельцы данных должны обозначить критичные данные и описать требования к их качеству.
4. Чтобы избежать дублирования или разночтения между отдельными предметными областями, информационный архитектор должен структурировать все описанные данные и разложить их в модель - обычно, это корпоративная модель данных.
Так что одни архитекторы тут не справятся, потребуются дата-стюарды для обеспечения процесса сбора описаний к данным и активное вовлечение бизнеса. Потом займётесь не критичными данными))
А вообще, приходите ко мне в телеграмм-канал, там много инфо вот про это всё (в профиле есть ссылка).
Хорошая идея, спасибо, подумаю об этом.
Ну тут, конечно, соглашусь - ничто не вечно под луной. Модели, которые мы используем сегодня, будут не релевантный нашему образу жизни завтра.
Оберег принят ) спасибо
Все штуки у всех так или иначе из книжек. Я всегда всем не перестаю повторять - берите любую заумную модель и пробуйте натянуть ее на себя, если взлетит - повезло, если нет - не ваше или носить не умеете )))
К чему я - нет смысла всё прикладывать к себе один к одному, нужно уметь адаптировать хорошие вещи под свои кейсы. Копните поглубже сами, прежде чем чужой столетний опыт подвергать сомнениям ))
Вы прекрасны! Многие знания - многие печали )
Мне кажется, что иногда не нужно пытаться объять необъятное - вселенная непредсказуема, а время быстротечно. Как бы мы ни гнались за модой, она изменится.
Я лишь пытаюсь здесь и сейчас использовать предложенную Захманом модель для нужд моделирования данных, и неплохо получается. Но, конечно, не поручусь, что спустя сотню лет эти же знания будут востребованы и применимы как прежде.
Прошу простить меня за невежество и позвольте пригласить в свой канал - @DataGovernance4all , где с удовольствием подискутирую с вами и выслушаю прочую критику к моим постам.
Это все про Data Governance - про руководство данными. Все описанные фреймоврки могут и используются для повышения управляемости и качества данных.
Именно поэтому Время фиксируется некими событийными фактами - или в прошлом или в будущем.
Конечно, мы не можем "поймать время за хвост", но описать будущие или свершившиеся факты через статусные или событийные модели - вполне себе в состоянии.
Что же вам всё таки смущает? Тот факт, что мы каким-то образом пытаемся зафиксировать или смоделировать время?
Event - это как раз про время, оставила классическое название от Захмана. В работе - да, там везде Time использую для очевидности. Если на сам Фреймворк посмотреть, то видно, что рядом с Event стоит вопрос "когда?"
Хорошая мысль, спасибо за предложение. Сегодня фреймворки используются везде, лучше будет уточнить назначение