Правила IT Архитектора - вступление
Вавилонская башня - известный всему миру пример великого замысла, который провалился.
Причина провала - внешнее вмешательство бога, который заставил людей говорить на разных языках, и те просто не смогли продолжить совместную работу над проектом.
В современном мире отсутствие общего языка, типовых инструментов и хорошо специфицированных требований приводит к провалу множества IT-проектов и без воздействия извне.
К счастью, у некоторых IT-проектов, есть люди, которые могут помочь исполнить задуманное - это IT-архитекторы.
Эти профессионалы призваны решать целый спектр проблем и вопросов, принимать решения различной степени сложности, а порой и менять первоначальные замыслы. И всё это ради того, чтобы достичь результата по его духу, а не по формальному описанию.
И конечно, каждый такой специалист накапливает свой багаж знаний, получает свои уникальные умения и выносит свои выводы и суждения.
Ведь башня огромная, и каждый смотрит на неё со своего угла, компетенций и яруса, на котором он работал.
Здесь я хочу описать свой опыт строительства башни, рассказать о своих ошибках и правилах ведения архитектуры.
Если вдруг вы окажетесь на моей стороне башни, возможно, эти советы будут вам полезны и спасут от досадных ошибок, потраченных нервов и необходимости начинать если не с нуля, то с пары шагов назад.
Правило 1. «Документируйте свои решения, особенно временные»
Комментарий недоступен
Ну не совсем, требования не панацея. Об этом ещё будет. В первую очередь важна коммуникация и контакт между заказчиком и архитектором.
Да, заказчик и архитектор работают напрямую. Есть два ключевых артефакта - Обзор решения, это верхнеуровневое понимание бизнес задачи. Оно описывает цели и эффекты для бизнеса и верхнюю картину того, что надо сделать в IT и тут работает архитектор. Когда решение принято, то его уже превращают в дизайн и тогда в работу включаются аналитики. Технологии выбираются перед тем, как отдать в разработку, а не наоборот.
Я встречал названия
Обзор решения: Solution overview, high-level design, Conceptual design, Statements of work, Change Request. Даже Use Case сюда можно отнести.
Дизайн решения: Detail level design, техническое задание, Solution Design, ОТАР (общеотраслевое технико-архитектурное решение)