Архив рубрики: архитектура ПО

Мнение о книге "Распределенные системы. Паттерны проектирования"

 

Книга совсем небольшая, порядка 220 страниц. Мне понравилась структура. Есть три части, в каждой дается вводная часть, описывающая группу паттернов, а затем главы посвящены отдельным паттернам. Каждый паттерн рассматривается теоретически, описываются случаи когда он может быть применен и, самое главное, приводится пример как его реализовать (докер, кубер и kubectl).

Выбор паттернов, как по мне, достаточно специфичен. Здесь нет той же Саги, зато есть очень много советов, как сделать контейнеры реально переиспользуемыми. Одноузловые паттерны это вообще тема, очень мало кто знает про них в достаточном объеме. Тот же прицеп еще на слуху, а амбасадор, уже вызовет вопрос, а что это такое :)

Читать ли книгу? Как по мне, так полезность очень высока. Даже если вы все это уже знаете, будет полезно посмотреть с другой точки зрения, да и конкретные приемы развертывания попадаются достаточно интересными. Единственно, я не могу рекомендовать эту книжку совсем уж новичкам. Скорее она ориентированна на уровень, когда человек уже набил некоторое количество шишек, а тут ему подсказка, как их не набивать в следующий раз.

Архитектор, а какой ты?

Статья подготовлена для корпоративного портала.

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

В прошлых статьях мы обсудили, кто такой архитектор и какую пользу он приносит компании. Сегодня предлагаю поговорить, а какие архитекторы бывают.

Родоначальником формализации архитектуры корпоративных информационных систем можно считать Джона А. Захмана со статьями «A framework for information systems architecture» и «Extending and formalizing the framework for information systems architecture», в которых и было описано то, что получило название модель Захмана.



Данная модель, несмотря на сложный вид, продвигает достаточно простую концепцию. Для разных людей при описании разных частей системы (под системой здесь понимается все предприятие) необходимо использовать разные модели, главное, чтобы они согласовывались между собой. Сам Захман пояснял это на примере строительства загородного дома. Архитектор садится с заказчиком и высокоуровнево обсуждает, что должно быть на участке и в доме. Результатом такой работы является концептуальный план, который в процессе работы архитектора превратиться в план водоснабжения для сантехников, архитектурный план для строителей, план электропроводки для электриков. И задача архитектора следить, чтобы все эти планы были между собой согласованы (чтобы не получилось, что водоснабжение придет в спальню, вместо санузла). 

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

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

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

На этом цикл концептуальных статей про архитектуру можно заканчивать и переходить к самому интересному - к деталям. 

Архитектор, а зачем ты нужен?

Статья подготовлена для корпоративного портала.

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

Чем занимаются архитекторы, мы с вами в прошлый раз поговорили, но вот какая от этой деятельности польза? Давайте взглянем на взаимосвязь архитектурных артефактов, предлагаемую Togaf (можно и в модель Захмана посмотреть, и в следующий раз даже посмотрим, но для текущей темы картинка из Togaf нагляднее):
Широта охвата нас пока не интересует, а вот основные домены и уровень погружения в компанию очень даже.

Если взять небольшую компанию или небольшой проект/продукт, то о вопросах архитектуры там говорить сложно, как правило есть некий сотрудник, у которого все в голове. Это может быть основатель стартапа, опытный программист, занимающийся автоматизацией деятельности с основания компании, или еще кто-то. Затраты на поддержание целостной картины минимальны, но и получить плюсы от этих знаний бывает проблематично, особенно когда человек в отпуске или после его ухода из компании. Чтобы подстелить соломку, возникает потребность в документации архитектуры (текущего состояния и принимаемых решений). А вот эта работу уже начинает требовать инвестиций. Пусть на первом этапе и небольших, но кто-то вместо того, чтобы работу работать, начинает заполнять какие-то таблички, строить диаграммы, рисовать схемы. И именно в этот момент наблюдается странный парадокс: затраты видны сразу, а видимость эффекта очень сильно зависит от домена, на котором начинается эта активность.

Когда за работу берутся IT специалисты, - не важно: разработчики, описывающие архитектуру приложений, или системные администраторы, описывающие технологический слой, - то эффекта на первых порах как такового нет. Ну появились какие-то документы, так чем читать описания и разбираться в диаграммах, проще подойти к знающему человеку и спросить у него: т.е. абстрактный архитектор тратит время на фиксацию архитектурных артефактов и, как и раньше, на ответы. Пользы от диаграмм нет. Чтобы польза появилась, команда должна стать достаточно большой или должно пройти значительное время. При большой команде времени архитектора на всех не хватает, и люди вынуждены обращаться к другим источникам знаний. А время расставляет все по местам, помним про отпуска? Что делать, когда знающего человека нет на месте? Правильно: искать документы. А после того, как первый раз получил ответ в документации, второй… Да еще не надо ждать, пока занятый другими коллегами архитектор ответит… Люди начинают этим пользоваться. Бизнес, как правило, эффект не очень видит, но, с точки зрения IT специалистов, наблюдается снижение сложности новых доработок.

Бизнес, со своей стороны, начинает со слоя бизнес-архитектуры. Нет, обычно это так громко не называется, но появляется описание процессов, расписываются зоны ответственности, начинается оптимизация, - и бизнес от этого сразу видит выгоду. Все действуют по одному алгоритму, обучение новых сотрудников упрощается, отдача от уже работающих – повышается. IT подразделения тоже на этом могут выиграть: ведь понимая, как работает бизнес, намного проще его автоматизировать. Не знаю, с чем это связано, но в большинстве организаций, с которыми приходилось сталкиваться, наблюдалась интересная картина: у бизнеса с описанием бизнес-процессов все более или менее хорошо, у IT одна из основных проблем, - они не понимают, как работает бизнес и те решения, которые реализуются, в бизнес возможности не превращаются. И получается ситуация, когда обе стороны не довольны друг другом. Бизнес, который знает, как он работает, и почему IT ему не помогают с автоматизацией этого - он не понимает. IT, с которого требуют что-то автоматизировать, но по итогам автоматизации рассказывают что это совсем не то, что нужно бизнесу.

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

Архитекторы, как и менеджеры, любят матрицы 2 на 2. Не откажу себе в удовольствии и основное содержимое статьи отображу именно в виде такой матрицы:

Главное, не забывайте, что перейти из «Отсутствия архитектуры» в «Корпоративную архитектуру» за один прием не получится. Это долгий процесс, который, возможно, какое-то время будет идти двумя отдельными ветками бизнес- и IT-архитектур с последующим их объединением, а, может быть, и подтягивание недостающей IT-архитектуры к тому, что уже есть в бизнес-архитектуре. У каждой компании в этом процессе может быть свой путь.


Возвращаясь к вопросу, а при чем здесь архитекторы? Как раз при том, что это их задача помочь компании осознать этот путь и объединить разрозненные кусочки информации, которые известны бизнесу, IT, другим заинтересованным лицам в единую картинку, которая в итоге и получит название корпоративная архитектура. О том, какими бывают архитекторы в этом процессе, мы поговорим в другой раз.

Архитектор, кто ты?

Статья подготовлена для корпоративного портала.

Все сложные системы так или иначе выйдут из строя. Между малым и большим, между совершенным и несовершенным есть некий человек или люди, у которых было видение формы вещей; мы называем таких людей "архитекторами". 
-- Гради Буч 

Так получилось, что в рамках проектов консалтинга за последние несколько лет была возможность заглянуть в несколько достаточно крупных (ну и не очень крупных) компаний, занимающихся внутренней или заказной разработкой. Практически во всех этих компаниях были люди, которые в названии должности имели слово «архитектор». Но вот то, чем они занимались, было от области бизнес аналитики до построения хрустальных замков и демонстрации их бизнесу. То, что ниже - это общее виденье, за что же должна отвечать роль архитектора, а о типах архитекторов и детальках их работы поговорим в другой раз.



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

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

Работа по восстановлению архитектуры выполняется архитектором, как правило, индивидуально. Это не означает, что он не общается с техническими специалистами, пользователями систем, другими архитекторами. Нет, это означает, что он собирает информацию, запирается (может быть даже и в башне из слоновой кости) и заполняет таблицы, пишет описания, рисует диаграммы. Остальные заинтересованные лица в этом процессе участвуют как поставщики информации и верификаторы на объективность зафиксированных данных. Да, эти архитектурные артефакты объективны. Они нацелены, чтобы максимально полно отображать окружающую действительность. Самая глобальная ошибка, которую может допустить архитектор на этом этапе, поверить кому-то на слово, не проверив ту самую пресловутую объективную реальность. Сказал разработчик что в таблице пять полей? Отлично, идем и проверяем. Сказал администратор баз данных, что кластер под СУБД из трех машин? Аналогично, идем и проверяем. Самое сложное в этой работе, это осознание того факта, что эта работа на будущее оказывает очень и очень опосредованное влияние.

А вот после того, как появилось понимание, где мы находимся сейчас, можно переходить ко второй существенной части работы архитектора – к принятию архитектурных решений. И здесь ситуация меняется кардинально. Если до этого архитектор работал с объективностью, практически индивидуально, то при принятии архитектурных решений надо понимать, что все решения будут субъективны, иметь существенное влияние на будущее и не принимаются архитектором индивидуально.

В процессе выработки архитектурных решений, роль архитектора заключается больше в направлении заинтересованных сторон по наиболее оптимальному пути. Архитектор здесь прорабатывает варианты, рассматривает какие плюсы и минусы могут быть после их внедрения. Да, именно потому, что никто не знает, к каким последствиям приведет то или иное решение, мы уже не можем говорить о объективизме, все плюсы и минусы решений – субъективны. А дальше, имея фактуру вариантов, заинтересованные лица собираются и при фасилитации архитектора принимают решение. Не архитектор принимает решение, а заинтересованные лица. Архитектор может подготовить замечательное решение, которое решит все проблемы текущей архитектуры и откроет компании огромные возможности для дальнейшего развития, но если спонсор не может выделить на эти изменения достаточный бюджет, то идти по этому пути бессмысленно и надо искать другие, альтернативные варианты архитектурных решений, которые будут может и менее эффективны, но более реалистичны в текущих условиях. И это касается не только спонсора. Предлагает архитектор внедрить новую систему хранения данных, у компании специалистов по ее поддержке нет, на рынке готовых специалистов нет, внешних компаний готовых взять решение на поддержку нет. И что? Есть смысл переходить на эту систему хранения? Вполне возможно и есть, но надо будет включить в план работ не просто найм специалистов, но и их обучение. Или отказаться от архитектурного решения и, если сроки критичны, пробовать реализовывать на имеющемся у компании стеке или стеке, по которому реально найти специалистов.

Если обобщить все вышесказанное, то получается вот такая картина:

Так кто же такой архитектор?

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