В разных компаниях - больших и маленьких - в каждой занимаются доработками программного обеспечения (ПО), и у всех есть процессы проектирования и разработки информационных приложений. Где-то они лучше, где-то хуже, где-то очень верхнеуровневые, а где-то слишком детальные, каждый выбирает по себе. И задокументированы и оформлены через стандарты и шаблоны такие процессы у всех компаний по-разному. Но есть одна очень общая для всех черта - практика моделирования данных или отсутствует вовсе, или находится в зачаточном состоянии. 

Почему так вышло? Дело в том, что очень долгое время мы все - ит-специалисты - занимались внедрением вендорских систем и приложений, и культура моделирования данных в системной аналитике практически сошла на нет. Вендорские решения поставляются с уже готовой моделью данных, которую вам никто не показывает и не рассказывает, как она устроена. Поэтому со временем все забыли про этап моделирования данных, а потом и забыли, как это делать :) А штука это хорошая и полезная. 

Проблема прилетела откуда не ждали: при усложнении ИТ-ландшафта потребовалось интегрировать большое количество систем и приложений между собой. Пришлось ковыряться в таблицах и полях вендорских моделей, собирая описание источников данных. Мы, конечно, наловчились пользоваться реверс-инжинирингом и программами, которые умеют это делать: подключаются к базе данных неизвестного вам продукта и считывают модель данных, а некоторые могут её визуализировать. Но вопрос в том, что изначальный навык проектирования утерян, т.е. мы научились неплохо "читать" выгруженные данные, а вот создавать с нуля модель данных для приложения - это уже проблематично.

Но сегодня мой пост не про то, как создавать модели данных, а про их место в процессе проектирования и разработки самих приложений. Итак, предлагаю вам посмотреть, как всё устроено у вас: поднимите документацию, посмотрите, какие шаги (артефакты) требуются в вашем процессе разработки ПО, сравните, какой из приведённых ниже вариантов ваш.

Наиболее часто встречающийся вариант выглядит вот так:

Как видно, в "Варианте 1" документ Бизнес-требования каким-то магическим образом превращается в готовое ПО. Очевидно, что в черном квадрате зашиты все несистематизированные и нигде не задокументированные требования к ПО, собранные посредством различных интервью, писем-запросов и на прямых встречах с заказчиком.

Если вы пишете что-то маленькое и незначительное, что не жалко выбросить через пару месяцев или можно переписать полностью за пару недель - это ОК, такой вариант выглядит приемлемым и оптимальным. 

Но если вы создаёте программный продукт, которым планируете пользоваться не один год, то такой подход выглядит не очень хорошо, так как ваши бизнес-требования никак не связаны с готовым решением, и если разработчик продукта уйдёт, то будет очень трудно разобраться в том что, как и где лежит в вашей информационной системе.

Именно поэтому каждая компания пытается справиться с этим неудобным моментом, и появляются вот такие варианты реализации процесса разработки ПО:

Или, например, вот такие:

Но ни 2-й, ни 3-й варианты не избавляют нас от проблемы "черного ящика". 

Правильный вариант разработки программного обеспечения в наш век экономики данных :) должен выглядеть вот так:

Почему этот вариант хороший? потому что не теряется связь между отдельными этапами проектирования ПО и на выходе в продакшн у вас на руках будет полный набор артефактов, который поможет вам легко - в считанные часы! - разобраться как устроено ваше ПО, какие данные где лежат и как они между собой связаны. И можно обойтись без душного :) ТЗ.  Также это поможет вам:

- быстрее решать задачи по поставке данных отдельных продуктов и приложений в хранилище данных,

- облегчит процесс интеграции со сторонними системами и приложениями.

Для облегчения понимания умышленно исключены следующие процессы (артефакты):

- проектирование концептуальной модели данных;

- проектирование архитектуры ПО.

Эти шаги тоже очень важные, особенно на широком ИТ-ландшафте. Они помогают нам разбираться со структурой информационных активов в целом, дают общую картину и помогают поддерживать единые стандарты проектирования. В рамках разработки одного отдельно взятого продукта или приложения достаточно того, что вы видите в последнем варианте.

PS: В рамках этой статьи считаем, что физическая модель данных=системное проектирование, т.к. ФМД разрабатывается с учётом особенностей конкретных баз данных (выбранной технологии).