В общем, архитектура достаточно большой компании называется в целом назвается корпоративной архитектурой Enterprise архитектурой. Она описывает все уровни детализации и весь объём компании. Для любого архитектора связанного с ИТ важно взаимодействие ИТ с остальным бизнесом компании. Для большинства компаний бизнес зарабатывает, а ИТ обеспечивает эту возможность, и понимание как это происходит и что нужно поменять задача корпоративного архитектора. Для этого корпоративный архитектор работает с двумя слоями, составляющих корпоративную архитектуру: архитектурой бизнеса (бизенесс уровень) и ИТ-архитектурой (ресурсный уровень). Эти уровни взаимодействую через сервисы, предоставляемые ресурсным уровнем для бизнес уровня. Очень важно понять, что в большинстве случаев ИТ является обеспечивающей функцией компании (ресурсный уровень), и архитектор описывает текущую бизнес архитектуру компании (бизнес уровень) и подстраивает ИТ архитектуру, чтобы описанная бизнес архитектура функционировала как задумано её создателями. Создателями бизнес – архитектуры являются руководители отделов, функциональных блоков и подразделений. Именно они в точности знают, как должны работать их отделы. При этом они тоже, часто её берут не из головы, а опираются на уже существующие процессы, например, отдел продаж опирается на клиентский опыт, который они получили в других компаниях и к которому привыкли, или в результате переговоров. Уже сформированные процессы в бизнес – архитектуре используют возможности ИТ, но это не означает, что корпоративному архитектору нужно сделать ИТ архитектуру зеркальным отображение бизнес архитектуры. Напротив, если несколько процессов имеют схожие требования, то ИТ архитектура должна это унифицировать, если это возможно, обеспечить гибкость и масштабируемость в коротки сроки в след за изменения и ростом процесс, а также предлагать более эффективные пути решения задач.
* Политическая архитектура (или слой заитересованных лиц) – слой заинтересованных сторон, их функциональных и личных интересов и договорённостей между ними. Важно заметить, что заинтересованные стороны – это стороны, то есть защищающие свои интересы, которыми являются личные интересы, например, личный KPI, интересы отдела за которые они отвечают. В связи с этим, архитектор не может подчиняться IT диретору, так как у него свои интересы, которые могут находится в аппозиции с интересами с директорами других подразделений. С другой стороны архитектору необходим политический покравитель, иначе артефкты не будут полностью реализованы. Генеральный дерекор тоже не может руководить архитектором, так как он не погружён в текущую внутреннюю действительность и у он занят в первую очередь внешней политикой и дипломатией. Наиболее погружёнными и компетентными являются директора, а коллегия их (архитектурный совет) уравновешивает интересы и синергирует компетенции. Империческим методом выяснено, что для архитектора на 50% важно сбор информации, ещё на 30% вести договариваться, и только на 20% выбор техничеких решений. Главным заинтересованной стороной является спонсор – тот человек, который заинтересован в проекте и обеспечивает его внешнюю защиту и внешнее продвижение. Спонсор на вмешивается в работу архитектора или менеджера, а решает проблемы, как миинимум связанные с выделением (приоритизации) ресурсами, с приоритизацией бэклога смеждных команд для интеграции и с противниками. Важно не путать спонсора, как силы придающей дижению проекту с теми, на кого возложена обязанность в обеспечении прокта, например, в случае фининсрования – бухгалтерия, а вслучае кадров – другие подразделения и кадровая служба. Именно спонсор своиим влиянием это обеспечивает и договариваться имеет смысл имеенно с ним, а не с теми, на кого спущено указание, так как они могут даже быть не заинтересованы, но не могут не сделать требуемое, и конечно же только в объёме спущенным спонсором. Важно, чтобы время у спонсора хватало для решения сложностей проекта, но при этом не слишком ного, чтобы самому руководить процессом этого проекта. Как и проект без спонсора, так и корпоративная архитектура без спонсора обречены на провал. О последнем говорится и в TOGAF, и в COBIT. Изменение архитектуры подразумевает проект, а следовательно процесс выявление заинтересованных сторон сопособные на него влиять. Выявление заинтересованных сторон можно взять из проектного упраления. Если заинтересованные стороны не выявлены или ника ещё себя не проявили – это может повлеч затраты, когда это заинтересованное лицо начнёт оказывать влияние и прийдётся на последних этапах подстраивать результат под него. Систематитизировать заитересованные стороны поможет матрица коммуникации. Матрица коммуникации представляет из себя таблицу заинтересованных сторон и их параметров. Часто, колючевые заитересованные стороны не заинтересованные в успешном завершении проэкта выбирают стратегию избегания, но без них проект не сможет завершиться. При выявлени заинтересованных сторон важно различать формальную организационную стуктуру и фактическую – ролевую. В проектах очень много задейсвуются горизонтаотных и диагональных связей. Выявить их можно, зачастую, только при общении, так как сформированны они были при общении. Например, сотрудник может быть "припаркован" в другом отделе. При наличии информации об интересах переговоры проходят гораздо легче, так как не нужно во время них их искать, и их результат проще зафиксировать в протоколе. При поиске данных нужно находить различные решения. Это отдельный навык – на искомых данных писк альтернативных решений, именуемый дивергентное мышлением. На переговорах важно услышать собеседников, предложить различные варианты сделав акцент (продать) не лучшие решения, найти компромисное решение. На уже имеющихся данных из большого числе решений нужно найти лучшее решение, что у технических специалистов, обычно, не вызывает сложностей, так как им привычно конвергентное мышление. Для архитектора основными контрагентом (основным стейкхолдером) являются владелец продукта для которого делается архитектура. Исключение одно, если решения принимают другие стейкхолдеры, а владелец продукта транслирует эти решения. Другие заинтересованные стороны: заказчик (или владерел продукта, как его представитель), разработчики (минимизация работы, четкую постановку задач, Time2Market), сервисные подразделения (выполнение их стандартов), архитектор сервиса (гарантированная работа сервиса), корпоративный архитектор (поддержания ландшафта). Если же не достигается взаимопонимание, то экскалировать нужно или архитектору данной области, или владельцу данной области. Наример, если не находится общий язывк с командой сервиса, можно эскалировать или владельцу сервиса, или архитектору сервиса. Если же не находится язык с владельцем сервиса, то эскалируется архитектору сервиса, если с архитектором сервиса, то владельцу это сервиса. Если же не находится общий язык ни с тем, ни с другим, стоит задаться вопросом, чьи интересы Вы отстаиваете. Заказчик хочет для бизнеса:
** планируемый процесс;
** минимизация рисков;
** движение к цели.
* Бизнес архитектура – это отображение деятельности предприятия и связи. Состоит она по TOGAF из ряда архитектр, а поскольку они является описательными, их часто:
** организационной архитектуры (бизнес цели, люди, роли),
** продуктовой архитектуры (продукты, каналы сбыта, клиентский путь),
** процессной архитектуры, связывающей организационную с продуктовой, как продавца и покупателя процессами.
* ИТ архитектуру делят на:
* Архитектура приложений – сдесь выделяют сами системы и проложения, которыми пользуются на бизнес слое, чтобы реализовать их процессы.
* Информационная архитектура – это совокупность информации (данных), которыми обмениваются люди или приложения в рамках выполнения процессов. Более подробно в разделе об моделировании данных.
* Архитектура приложений – архитектура управления ландшафтом решений (приложений, систем) и их составом. Корпоративный архитектор заботится на этом уровне над встраиванием новых систем и унификации технологий, на которых они построены. Для этого он пользуется ландшафтом (картой) бизнес решений компании, проектирует платформенные решения, проводит унификацию применяемые технологий при реализации решений и создаёт стандарты их применения. Системными драйверами изменения могут быть экономические показатели, показатели безопасности, скорости роста или адаптации на изменения. Примером подобной унификации может быть выбор минимально достаточного набора языков закрывающего основные потребности для уменьшения стоимости сопровождения систем как с технической точки зрения, так и с кадровой. Примерами трансформации архитектуры может быть переход с монолитных систем на компонентные (SOA), или с SOA на микросервисные, для всего этого требуется разработка стандартов и выбора соответствующих технологий, что позволяет увеличить Time2Market и перейти на более дешёвые аппаратные системы (x86) и отказаться от оплаты лицензий за проприетарное программное обеспечение. Архитектор решения проектирует само решение, согласуя встраивание его в корпоративный ландшафт решений и следование стандартам унификации технологий, применяемый при проектировании решений.
* Интеграционная архитектура связывает различные компоненты системы и именно эти связи и описывает интеграционная архитектура.
* Техническая архитектура описывает реализацию предыдущих слоёв. Сама она тоже делятся на слои, но эти слои не абстракции, а являются технической реализацией относительно клента. Эти слоит также называются технологическим стеком, так как они располагаются от пользователя бизнес слоя один за другим в определённом порядке и ни одни слой не может быть пропущен, в то время, как слои архитектуры описывают архитектуру под разным способом, могут дополняться и изменяться, но мы придерживается принятому в TOGAF набору слоёв. Так, стек WEB приложений состоит из:
** Слой приложений – тот слой с которым непосредственно взаимодействуют пользователи и которые обеспечивают процессы и реализуется с помощью WEB интерфейсов в браузерах. Выполенине же бизнес логики на уровне WEB интерфейсов недопустимо – вся работа делегируются нижележащему слою.
** Сетевой слой обеспечивает работу WEB интерфейсов в браузерах пользователях, передавая данные. Вышестоящий слой приложений нужен пользователям, которым удобно пользоваться графическим интерфейсом и чтобы за них выполнялись какие либо рутинные действия. Сетевой слой обеспечивает коммуникацию серверных приложений, таких как WEB-сервера и СУБД.
** Аппаратный слой представлен устройствами выполннения. Эти устройства могут аппаратными с разной степенью универсальность. Например, балансировщик может быть чисто аппартным, может быть аппаратным с изменяемой прошивкой, может быть программным исполняемым на универсальной вычислительной машине типа x86, может быть запущен как непосредственно, так на виртуальной машине, так и в контейнере – всё это детали реализации.
** Слой хранения данных состоит из устройств хранения данных. Этими устройствами могут быть специализированные устройства типа IBM DataPower или же обычный RAID с управляющим модулем. Данные в нём полностью описывают состояние и является результатом работы, а предыдущие слоит только нужны для изменения и предоставления удобного доступа пользователям.
При необходимости, могут быть внедрены и другие слои, например:
* слой информационной безопасности реализуемый файрволл;
* слой базовых образов контейнеров;
* слой локальной отказоустойчивости (HA) на примере слоя Kubernetes;
* слой контейнеризации;
* слой виртуализации;
* слой устойчивости к авариям реализуемый балансировщиками на разные DataCenter.
В любом случае количество слоёв стандартизируется на уровни компании, чтобы каждый слой относился с определённым инфраструктурным отделом и отделом эксплуатации. Возможно, в технологическом стеке указывают только те, которые отличаются для акцента на них. Так, если все построены на x86 или Linux, то нет смысла это указывать, но чтобы сохранить историчность, когда это было не так, их можно объединить. Также можно объединить, если верхние слои строются исключительно на определённых слоях нижнего. Так, в стеке для OpenShift нет смысла указывать операционную систему или тип контейнеризации, так как он определён самой платформой OpenShift и для корпоративного архитектора это не имеет значение.
Если сравнивать корпоративного архитектора и архитектора решения, то можно установить, что они работают в связке, работают на всех уровнях архитектуры, но преследуют разные цели:
* корпоративный архитектор представляет интересы всего IT ландшафта;
* архитектор решения преследует интересы конкретного решения и его заказчика.
С одной стороны может показаться, что корпоративный архитектор главнее архитектора решения, или как миниму его интересы есть сумма интересов всех архитекторов ршений, но это не так. С точки зрения роста из разработчика такая лесенка имеет место быть: Junior Developer, Developer, Sinir Developer, Lead Developer, Software Architect, Solution Architect, Enterprise Architect. Это так называемый путь I-T-E форма:
* Узкий специалист сперва осваивает в глубину свой узкую область, например, разработку на Java приложений.
* Потом осваивает свой кругозор в ширину (T) соседние области, повышая свой кругозор, чтобы задействовать другие технологии, например, Front-end для Java back-end. Это характерно для Software Architect, например, Java.
* затем появляется наращивание компетенций в бизнес фокусировке и управленческих навыках, так как большой проект создаётся для решения бизнес потребностей и им нужно управлять, что уже характерно для Solution Architect.
* следующим этапом является накопление навыков по бизнес стратегии, что необходимо для подготовки и корректировки развития IT ландшафта.
Корпоративный архитетктор:
* доменно развитием методологий и стандартов (технологий, архитектур);
* на уровне данных: разрабатывает концептуальную и логическую корпоративную модель данных;
* на уровне приложений: разрабатывает целевой ландшафт (карту) приложений;
* на уровне бизнеса: разарабатывает карту компетенций;
* осуществляет архитектурный консалтинг для архитекторов;
* разрабатывает архитектуру экосистемы;
* осуществляе архитектурный контроль на уровне компании;
* корректирует архитектуру по трендам, бизнес и технологическим статегиям;
* балансирует скороть и контроль.
Архитектор решения:
* транслирует бизнес идей в решения;
* защищает ахитектуру сквозных процессов вплоть до правления;
* учавствует в согласовании архитектур (бизнес процессов, приложений);
* разрабатывает концептуольнве архитектуры (интеграционные на разных уровнях);
* связывает системы в единое решение (процесс, продукт);
* синхронизирует работу архитекторов систем бизнес процесса;
* согласует решение с корпоратиными архитеторами на добавления в ландшафт;
* на собеседовании в основном вопросы по согласованию и поиску информации о различных системах.
Архтектор системы:
* разрабатывает архитектуру решения;
* осуществляе архитектурный контроль решения;
* помогает разработчикам;
* часто является экспертом;
* на собеседования вопросы по доменной области, портфолио – описания систем.
По заинтересованным лицам архитекторы отличаются:
* Software Architect – разработчики и пользователи этой программы;
* Domain Architect – все пользователи этого домена, например, баз данных;
* Solution Architect – бизнес заказчики процесса, в рамках которого нужно согласовать работу систем, обеспечивающих его;
* Enterprise Architect – все бизнес заказчики, владельцы платформы и систем, менеджеры, все другие заинтересованные лица.
Отличается и назначение:
* архитектор приложения сфокусирован на выбора технологий и проектировании;
* архитектор решения сфокусирован бизнес проблема, при этом решение не обязательно должно быть техническим, например, может быть организационным или управленческим, но безусловно, кругозор, абстрактно мыслить, умение быстро с требуемой глубиной разбираться в технологиях должны быть, но менее, чем коммуникационные навыки;
* корпоративный архитектор сфокусирован на целях компании, например, на уменьшение затрат на поддержку и содержание всех решений компании за счёт унификации технологий, уменьшении общего Time2Market за счёт автоматизации в DevOps или увеличении утилизации за счёт перевода всех решений в облако.
По целям отличаются:
* Архитектор решения стремится удовлетворить заказчика этого решения. Если он не использует платформенные решения и экосистему, то корпоративная архитектура для него накладные расходы. Да, ситуация изменится при эксплуатации и поддержке.
* Корпоративный архитектор забоится о компании в целом, даже у ущерб отдельным проектам. Так, использование определённых технологий может помочь проекту, но это повысит содержание и усложнит управление в целом для компании.
Также корпоративный архитектор подключается на этапах целепологания и планирования сервиса, а архитектор решения – на этапе проектирования и реализации.
Отличаются по навыкам:
* Software Architect – сфера влияния – команда разработки, а принимаемые решения, обычно, это чисто технические на основе спущенных требований;
* Domain Architect – требуется выполнять поручение заинтересованных сторон, поэтому достаточно уметь выслушать;
* Solution Architect – требуется согласовать работу нескольких систем участвующих в процессе, необходимо инициировать коммуникацию с владельцами этих систем, уметь понимать требования бизнеса;
* Enterprise Architect – необходимо формировать техническое развитие бизнеса, необходимо формировать проекты и их программы, определять стратегию, выстраивать вертикальные и горизонтальные связи, понимать и строить политическую обстановку.
Отличии в работе:
* Software Architect – проектирование приложение используя шаблоны проектирования, такие как GRASP;
* Domain Architect – проектирует и развивает свой домен;
* Solution Architect – проектирует изменения в продуктах и процессах, согласовывает работу архитекторов по слаженной работе;
* Enterprise Architect – определяет архитектурную стратегию развития направлений, архитектруные концепции, архитектурный ландшафт компании, презентует топ-менеджументу в презентациях, регулирует работу компании стандартами и другими активностями.