Проекты по созданию архитектуры данных и процессов, поддерживающих архитектурную деятельность, сопряжены со значительно бОльшими рисками, чем любые другие проекты, особенно во время первой такой попытки внутри организации. Самые серьезные риски бывают обусловлены следующими факторами:
- Отсутствие отдельного проекта по внедрению архитектуры данных в производственный цикл организации. Часто бывает, что архитектуру данных пытаются внедрить "попутно" с другими активностями, связанными с внедрением дата-практик в компании. Такой подход выглядит вполне нормальным и не противоречит общим целям, но все задачи, связанные с созданием и дальнейшим развитием дата-архитектуры, должны быть тогда четко определены и обозначены в общем скоупе проекта и, желательно, выделены в отдельный стрим, а также должен быть назначен ответственный за его реализацию - руководитель проекта или тимлид. В этом случае мы избежим ситуации, при которой про архитектурные задачи просто-напросто забудут или не будут уделять им должного внимания, так как на них не выделены ресурсы: бюджет, люди, не обозначены понятные сроки.
- Недостаточная поддержка со стороны руководства. Любой другой крупный проект, инициированный параллельно с задачами дата-архитектуры, способен повлиять на архитектурный процесс. Например, у руководства возникают вопросы или сомнения в отношении проведения архитектурной деятельности в рамках нового проекта, и оно может не дать согласия на продолжение участниками проекта их работ по созданию архитектуры данных. Лишь заручившись надежной поддержкой руководства в целом, можно рассчитывать на то, что архитектурный процесс переживет все изменения и реорганизацию в компании. Следовательно, необходимо постараться привлечь к процессу разработки архитектуры данных как минимум нескольких руководителей высшего или хотя бы старшего звена, понимающих преимущества архитектуры данных.
- Отсутствие документально подтвержденных достижений. Для успеха важно иметь твердого сторонника и поручителя (спонсора — sponsor) из числа старших по рангу, который к тому же не сомневается в способности команды выполнять функцию по созданию и сопровождению архитектуры данных. Полезно бывает заручиться поддержкой и привлечь в качестве консультанта на критически важных этапах проектирования кого-то из главных архитекторов или нанять в штат экспертов со стороны, или воспользоваться услугами консалтинговых компаний. Процесс создания ценностей от внедрения дата-архитектуры долгий и может занять несколько лет.
- Настороженность или обеспокоенность спонсора проекта. Если спонсор требует, чтобы всякий обмен информацией и сообщениями (равно как и все согласования) проходил строго через него/нее или отдельно выделенное доверенное лицо, это может указывать на различные неблагоприятные факторы: он/она или не вполне понимает свою роль, или боится за свое место, или преследует иные интересы, нежели те, что диктуются задачами проектирования архитектуры данных, или не уверен в способности архитекторов данных справиться со своими задачами. Причины для беспокойства у спонсора могут быть самые разные, но он обязан предоставить руководителю проекта и архитектору данных возможность выполнения ведущих ролей в реализации проекта. Необходимо всячески добиваться независимого положения специалистов, а также повышения уверенности спонсора.
- Контрпродуктивные решения руководства. Бывает так, что руководство вроде бы и осознаёт всю степень ценности хорошо организованной архитектуры данных, но не понимает, как обеспечить ее реализацию. Из-за этого могут внезапно приниматься решения, противоречащие усилиям архитекторов данных. Это свидетельствует не о потере поддержки cо стороны руководства, а всего лишь о том, что архитектору данных нужно чаще, четче и яснее доносить свою позицию до сведения руководства.
- Культурный шок. Отсутствие культуры данных в компании на момент создания архитектуры данных может свести на нет все попытки по её внедрению. Следует принимать в расчет то, как изменится рабочая культура тех сотрудников, которых затронет архитектурная деятельность. Можно попытаться представить, насколько просто или сложно им будет изменить свое поведение внутри организации. Необходимо поэтапное внедрение новых архитектурных процессов в производственный цикл организации, сопровождающееся обязательным получением обратной связи и обучением сотрудников. Также необходимо регулярно проводить корректировку отдельных шагов, чтобы упростить и облегчить процесс принятия изменений, но не в ущерб общим целям.
- Неопытный руководитель проекта. Необходимо удостовериться, что руководить проектом поручено лицу с достаточным опытом в области корпоративной архитектуры данных, особенно если значительная часть проекта связана непосредственно с данными. Если выяснится, что опыта недостаточно, убедите спонсора проекта либо заменить руководителя, либо провести его обучение.
- Одностороннее представление. Случается так, что владелец (owner) (или владельцы) одного из бизнес-приложений (например, ERP-системы) проявляют тенденцию навязывать свои взгляды на общую корпоративную архитектуру данных в ущерб более сбалансированному и всестороннему представлению. Необходимо строго придерживаться централизованных архитектурных принципов и стандартов, а не создавать под нужды отдельных бизнес-сервисов собственный слой архитектуры данных.
Статья подготовлена по материалам "Руководства по управлению данными DAMA-DMBOK".
Все новости канала можно получать и читать в телеграм: t.me/...all
