Архитектор и управление
Часто возникают споры, должен ли архитектор заниматься управлением. Дескать, управление это удел менеджеров, а архитектор просто снимает неопределенность.
В моём понимании, архитектор, останавливающийся на этапе проектирования – недо-архитектор. Обитатель башни из слоновой кости.
Ответственность за судьбу проекта требует внедрения (проталкивания) архитектурных решений.
И тут только два пути: либо реализовывать свой проект самому, либо управлять его реализацией.
Так что, хороший архитектор занимается управлением, в самом что ни на есть «кибернетическом» смысле слова.
#управление
Часто возникают споры, должен ли архитектор заниматься управлением. Дескать, управление это удел менеджеров, а архитектор просто снимает неопределенность.
В моём понимании, архитектор, останавливающийся на этапе проектирования – недо-архитектор. Обитатель башни из слоновой кости.
Ответственность за судьбу проекта требует внедрения (проталкивания) архитектурных решений.
И тут только два пути: либо реализовывать свой проект самому, либо управлять его реализацией.
Так что, хороший архитектор занимается управлением, в самом что ни на есть «кибернетическом» смысле слова.
#управление
👍1
Власть архитектора
Для того чтобы управлять нужна власть. Власть это всегда контроль над некоторыми ресурсами.
Если вспомнить известную в узких кругах управленцев байку о морковке, управленец должен иметь контроль над морковкой.
Конечно, можно и без контроля, но в этом случае мотивация уступает место манипуляции. Крайне нестабильный кейс.
Вопрос в тему, а какой властью обладает архитектор?
#власть
Для того чтобы управлять нужна власть. Власть это всегда контроль над некоторыми ресурсами.
Если вспомнить известную в узких кругах управленцев байку о морковке, управленец должен иметь контроль над морковкой.
Конечно, можно и без контроля, но в этом случае мотивация уступает место манипуляции. Крайне нестабильный кейс.
Вопрос в тему, а какой властью обладает архитектор?
#власть
Власть архитектора 2
Архитектор располагает тремя основными ресурсами:
1. Опытом. И может помочь разработчикам при решении сложных задач.
2. Знанием контекста задачи. Пока разработчики создают материальные ценности, архитектор пропитывается контекстом на различных совещаниях.
3. Ответственностью. Но здесь не раздает, а наоборот принимает на себя. Решение, которое не хочется принимать разработчику, может взгрузить на себя архитектор.
Проблема может возникнуть тогда, когда ресурсы архитектора не востребованы.
Например, слабые разработчики могут не понимать сложности задачи и не искать решений у более опытного товарища.
Вывод:
Архитектор может управлять процессом разработки только в случае наличия грамотной команды разработчиков мотивированных на реализацию проекта.
В противном случае архитектор работает в пустоту.
Архитектор располагает тремя основными ресурсами:
1. Опытом. И может помочь разработчикам при решении сложных задач.
2. Знанием контекста задачи. Пока разработчики создают материальные ценности, архитектор пропитывается контекстом на различных совещаниях.
3. Ответственностью. Но здесь не раздает, а наоборот принимает на себя. Решение, которое не хочется принимать разработчику, может взгрузить на себя архитектор.
Проблема может возникнуть тогда, когда ресурсы архитектора не востребованы.
Например, слабые разработчики могут не понимать сложности задачи и не искать решений у более опытного товарища.
Вывод:
Архитектор может управлять процессом разработки только в случае наличия грамотной команды разработчиков мотивированных на реализацию проекта.
В противном случае архитектор работает в пустоту.
👍3
Коллективный архитектор
Тенденция заменить архитектора "коллективом авторов"
вызывает у меня некоторую настороженность.
Вижу следующие проблемы:
1. Размытие ответственности. В моем понимании ответвественность может быть или персональной, или никакой.
2. Фрагментация архитектурного представления системы. Целевая архитектура это прежде всего целостный ментальный образ.
Превратить это в набор терминов или лог решений можно, но эти фрагменты не заменят начального представления.
Единый ментальный образ в нескольких головах одновременно - нонсенс (Исключение Ильф и Петров).
Поэтому архитектор один, а остальные, принимая решения, должны согласовывать их с владельцем исходной картинки.
Тенденция заменить архитектора "коллективом авторов"
вызывает у меня некоторую настороженность.
Вижу следующие проблемы:
1. Размытие ответственности. В моем понимании ответвественность может быть или персональной, или никакой.
2. Фрагментация архитектурного представления системы. Целевая архитектура это прежде всего целостный ментальный образ.
Превратить это в набор терминов или лог решений можно, но эти фрагменты не заменят начального представления.
Единый ментальный образ в нескольких головах одновременно - нонсенс (Исключение Ильф и Петров).
Поэтому архитектор один, а остальные, принимая решения, должны согласовывать их с владельцем исходной картинки.
👍3
4D Архитектура
Пришёл к выводу, что архитектурные решения необходимо фиксировать с привязкой ко времени (этапам работы).
Во-первых, это позволяет втискивать в описание планы миграции.
Во-вторых, я могу положить в описание целевую картину (зачастую недостижимую) и сверять с ней решения каждого этапа.
Как-то так
Пришёл к выводу, что архитектурные решения необходимо фиксировать с привязкой ко времени (этапам работы).
Во-первых, это позволяет втискивать в описание планы миграции.
Во-вторых, я могу положить в описание целевую картину (зачастую недостижимую) и сверять с ней решения каждого этапа.
Как-то так
https://medium.com/olzzio/the-markdown-adr-madr-template-explained-and-distilled-b67603ec95bb
Заметка по MADR (Мой любимый формат ADR))
Заметка по MADR (Мой любимый формат ADR))
Medium
The Markdown ADR (MADR) Template Explained and Distilled
The Markdown Any Decision Record (MADR) Template turned five on Nov 22, 2022; its Version 3.0 was released recently. MADR stems from…
Снова о CAP теореме
В тренде переосмысление CAP теоремы. В пору говорить о двух теоремах:
- CAP - как то задумывали математики
- cap - как это воспринимают продаваны и комьюнити.
О чем таки исходная CAP ?
Часто приводят простой пример (сам грешен):
При разрыве соединения между двумя бд мы не можем обеспечить идентичность записей на обеих. Либо работаем с различающимися копиями, либо останавливаем одну из.
После чего предлагается подход BASE (vs ACID) с итоговой согласованностью.
Правда в том ,что в итоге согласованности (в смысле CAP) не будет все равно.
CAP говорит об линеаризуемой согласованности и только о ней.
То есть при последующем восстановлении соединения порядок применения операций на разных бд может отличаться - и это математически не устранимо в общем случае.
Если ли выход ?
Да конечно - строгая итоговая согласованность.
#CAPТеорема
В тренде переосмысление CAP теоремы. В пору говорить о двух теоремах:
- CAP - как то задумывали математики
- cap - как это воспринимают продаваны и комьюнити.
О чем таки исходная CAP ?
Часто приводят простой пример (сам грешен):
При разрыве соединения между двумя бд мы не можем обеспечить идентичность записей на обеих. Либо работаем с различающимися копиями, либо останавливаем одну из.
После чего предлагается подход BASE (vs ACID) с итоговой согласованностью.
Правда в том ,что в итоге согласованности (в смысле CAP) не будет все равно.
CAP говорит об линеаризуемой согласованности и только о ней.
То есть при последующем восстановлении соединения порядок применения операций на разных бд может отличаться - и это математически не устранимо в общем случае.
Если ли выход ?
Да конечно - строгая итоговая согласованность.
#CAPТеорема
Смысл архитектора
Обсуждаем смысл существования архитектора.
Некоторые считают что, архитектор решает задачи заказчика и выполняет его цели.
Отчасти так. Особенно в плане неосознаваемых потребностей бизнеса.
Но кроме этого. Архитектор дает общее осмысленное представление решения. Тем самым резко снижает энтропию системы и ее (энтропии) рост.
Система не идет в разнос в обозримой перспективе и это хорошо, хоть и сложно объяснимо бизнесу.
А задачи и грамотный разработчик реализовать может.
Обсуждаем смысл существования архитектора.
Некоторые считают что, архитектор решает задачи заказчика и выполняет его цели.
Отчасти так. Особенно в плане неосознаваемых потребностей бизнеса.
Но кроме этого. Архитектор дает общее осмысленное представление решения. Тем самым резко снижает энтропию системы и ее (энтропии) рост.
Система не идет в разнос в обозримой перспективе и это хорошо, хоть и сложно объяснимо бизнесу.
А задачи и грамотный разработчик реализовать может.
Дерево принятия решений по согласованности. Задача
Загорелся идеей нарисовать дерево принятия решений по согласованности (консистентности)
В моем понимании критериями принятия решения должны быть допустимые феномены/артефакты рассогласования по стандарту 95 года (https://arxiv.org/ftp/cs/papers/0701/0701157.pdf) и приемлемые уровни доступности (полная, постоянная, частичная).
Однако в процессе осознал, что в такой постановке задачу на достижение согласованности ни разу не получал.
Хотелось бы провести опрос (ниже)
#CAPТеорема
Загорелся идеей нарисовать дерево принятия решений по согласованности (консистентности)
В моем понимании критериями принятия решения должны быть допустимые феномены/артефакты рассогласования по стандарту 95 года (https://arxiv.org/ftp/cs/papers/0701/0701157.pdf) и приемлемые уровни доступности (полная, постоянная, частичная).
Однако в процессе осознал, что в такой постановке задачу на достижение согласованности ни разу не получал.
Хотелось бы провести опрос (ниже)
#CAPТеорема
По посту выше.
В какой форме Вы получали запрос на обеспечение согласованности/изолированности данных
В какой форме Вы получали запрос на обеспечение согласованности/изолированности данных
Anonymous Poll
15%
В форме указания допустимых протоколов (RAFT, Paxos и т.п.)
8%
В форме указания уровня согласованности или изоляции (напрмер требуется казуальная согласованность)
8%
В форме указания концепции (ACID, BASE, newACID)
0%
Списком допустимых артефактов/феноменов
54%
Ничего не получал, требования придумывал сам
46%
Не сталкивался с этой задачей
Выбор БД
Зачастую при выборе БД используется подход Technology First.
Причины:
1. Нас зацепила реклама и порожденный ею хайп
2. Мы хотим оставаться в тренде (разработка ведомая резюме)
3. Мы используем "проверенный" продукт. И в случае чего можем списать неверный выбор на общую тенденцию.
Ну и самое главное - мы зачастую не умеем выбирать, ориентируясь на задачи и цели.
Например:
Заказчик хочет сохранять метаданные в гео-распределенной системе с поддержкой протокола синхронизации RAFT или аналогичного (так в ТЗ ))
Варианты решения:
- У нас есть проверенный годами инструмент zookeeper. Зачем еще что-то придумывать ?
- Я очень хочу попробовать Cassandra. Возьмем ее
- В распределении хороша MongoDB. Да, все сидят на монге!
А как иначе ?
Если бы я делал ответственный выбор, я бы взвесил следующие качества:
1. Изолированность (на первом месте)
2. Согласованность (синхронизация копий)
2. Отказоустойчивость
3. Доступность
4. Производительность
И если уж начинать с изоляции, то нужно правильно сформулировать задачу.
Судя по опросу, да и по опыту, писать задачу от феноменов бессмысленно.
Я бы зафиксировал типы транзакций и операций, участвующих в транзакциях. И отсюда вывел бы требуемый уровень.
Например так:
5. В транзакциях могут быть операции вставки и операции чтения по предикату
Возможны фантомы, Phantom
Решения:
1. Модель акторов (сервис, обрабатывающий транзакции по очереди)
2. Предикативная блокировка
3. MVCC с откатом опасных транзакций нарушаемых вставкой
4. Транзакция от уровня Serializable
И это сразу бы сузило число претендентов на МОЮ БД )
#БД
Зачастую при выборе БД используется подход Technology First.
Причины:
1. Нас зацепила реклама и порожденный ею хайп
2. Мы хотим оставаться в тренде (разработка ведомая резюме)
3. Мы используем "проверенный" продукт. И в случае чего можем списать неверный выбор на общую тенденцию.
Ну и самое главное - мы зачастую не умеем выбирать, ориентируясь на задачи и цели.
Например:
Заказчик хочет сохранять метаданные в гео-распределенной системе с поддержкой протокола синхронизации RAFT или аналогичного (так в ТЗ ))
Варианты решения:
- У нас есть проверенный годами инструмент zookeeper. Зачем еще что-то придумывать ?
- Я очень хочу попробовать Cassandra. Возьмем ее
- В распределении хороша MongoDB. Да, все сидят на монге!
А как иначе ?
Если бы я делал ответственный выбор, я бы взвесил следующие качества:
1. Изолированность (на первом месте)
2. Согласованность (синхронизация копий)
2. Отказоустойчивость
3. Доступность
4. Производительность
И если уж начинать с изоляции, то нужно правильно сформулировать задачу.
Судя по опросу, да и по опыту, писать задачу от феноменов бессмысленно.
Я бы зафиксировал типы транзакций и операций, участвующих в транзакциях. И отсюда вывел бы требуемый уровень.
Например так:
5. В транзакциях могут быть операции вставки и операции чтения по предикату
Возможны фантомы, Phantom
Решения:
1. Модель акторов (сервис, обрабатывающий транзакции по очереди)
2. Предикативная блокировка
3. MVCC с откатом опасных транзакций нарушаемых вставкой
4. Транзакция от уровня Serializable
И это сразу бы сузило число претендентов на МОЮ БД )
#БД
👍2
Выбор БД
В продолжении темы хотел бы поделиться ссылкой на аналитику которую использую при выборе БД.
http://jepsen.io/analyses
Коллеги, если знаете что-то аналогичное пишите в комменты.
Буду очень благодарен 😌
В продолжении темы хотел бы поделиться ссылкой на аналитику которую использую при выборе БД.
http://jepsen.io/analyses
Коллеги, если знаете что-то аналогичное пишите в комменты.
Буду очень благодарен 😌
👍3
Архитектура как набор документов
По поводу документирования архитектурных решений существует широкий спектр мнений.
От "документировать ничего не нужно" до "архитектура это и есть документ".
Те, кто считают, что документирование имеет смысл выделяют три функции документа.
1. Объективизацию
Архитектор "отчуждается" от решения. Смотрит на него со стороны. Более объективно
2. Коммуникацию
Архитектор доносит свою мысль до стейкхолдеров.
3. Архивацию
Мысль архитектора сохраняется. Может быть многократно использована или пере-использована.
Подо все это есть свои виды документов, заточенные на выполнение конкретных функций.
1. ADR (запись архитектурного решения)
Это объективизация. Используется в процессе решения конкретной задачи.
Здесь архитектор перебирает варианты, строит модели, фиксирует данные прототипирования.
Здесь же фиксируется решение.
Я предпочитаю фиксировать сразу несколько решений
- Как будет на следующей итерации
- Как будет в итоге (целевое решение)
- Идеальное (обычно недостижимое) решение
Ну и плюс миграция от одного к другому
Подход 4D
2. RFC (документ для обсуждения)
Многие предполагают, что это стадия ADR. То есть для обсуждения предлагается использовать законченую ARD.
Мы у себя в команде находим это несколько неудобным.
Почти так же не удобно как есть на кухне.
Зачем посвящать всех стейкхолдеров в детали и нюансы принятия решений.
Можно выхолостить ADR. Оставить только выводы и отдать на обсуждение.
3. AD (архитектурное описание)
Когда-то это был единственный документ, представляющий архитектуру. Обычно многотомник.
Здесь итоги решений сведены к описанию системы в целом. Уже без привязки к отдельным решаемым вопросам.
В принципе можно обойтись и без AD.
RFC содержат всю информацию по системе. Однако RFC это фрагменты - и их надо собрать.
Намного проще иметь диаграммы компонент и развертывания в одном месте.
Раньше этот документ распечатывался и раскидывался по столам стейкхолдеров.
Теперь он электронный и может быть фрагментирован.
#ArchDoc
По поводу документирования архитектурных решений существует широкий спектр мнений.
От "документировать ничего не нужно" до "архитектура это и есть документ".
Те, кто считают, что документирование имеет смысл выделяют три функции документа.
1. Объективизацию
Архитектор "отчуждается" от решения. Смотрит на него со стороны. Более объективно
2. Коммуникацию
Архитектор доносит свою мысль до стейкхолдеров.
3. Архивацию
Мысль архитектора сохраняется. Может быть многократно использована или пере-использована.
Подо все это есть свои виды документов, заточенные на выполнение конкретных функций.
1. ADR (запись архитектурного решения)
Это объективизация. Используется в процессе решения конкретной задачи.
Здесь архитектор перебирает варианты, строит модели, фиксирует данные прототипирования.
Здесь же фиксируется решение.
Я предпочитаю фиксировать сразу несколько решений
- Как будет на следующей итерации
- Как будет в итоге (целевое решение)
- Идеальное (обычно недостижимое) решение
Ну и плюс миграция от одного к другому
Подход 4D
2. RFC (документ для обсуждения)
Многие предполагают, что это стадия ADR. То есть для обсуждения предлагается использовать законченую ARD.
Мы у себя в команде находим это несколько неудобным.
Почти так же не удобно как есть на кухне.
Зачем посвящать всех стейкхолдеров в детали и нюансы принятия решений.
Можно выхолостить ADR. Оставить только выводы и отдать на обсуждение.
3. AD (архитектурное описание)
Когда-то это был единственный документ, представляющий архитектуру. Обычно многотомник.
Здесь итоги решений сведены к описанию системы в целом. Уже без привязки к отдельным решаемым вопросам.
В принципе можно обойтись и без AD.
RFC содержат всю информацию по системе. Однако RFC это фрагменты - и их надо собрать.
Намного проще иметь диаграммы компонент и развертывания в одном месте.
Раньше этот документ распечатывался и раскидывался по столам стейкхолдеров.
Теперь он электронный и может быть фрагментирован.
#ArchDoc
🔥3👍1
Роль Архитектора
На выходных обсуждали роль архитектора в принятии архитектурных решений.
Было высказано два тезиса:
1. Архитектор не принимает решения. Это делают менеджеры. Роль архитектора переоценена.
2. Архитектурные решения хорошо принимаются и без архитектора.
Позволил себе не согласиться )
1. То, что менеджерам кажется разумным и единственно верным решением - это то же решение принятое каким-то архитектором. Только чужим.
2. Если это решение стало популярным или даже необходимым, значит это кому-нибудь нужно. То есть кто-то с этого зарабатывает. Не вы.
3. Свой архитектор мог бы разработать альтернативное решение для своего бизнеса. Тут нужны навыки и опыт.
4. Свой архитектор может хотя бы сбалансировать интересы чужого и своего бизнеса.
5. Если вы ещё не почувствовали зачем вам нужен архитектор, то он вам и не нужен. Для архитектуры нужно созреть.
А в общем как и везде. Можем взять свое решение, но кто его будет делать. Или платить за чужое, но дорого, и результат непредсказуем.
#РольАрхитектора
На выходных обсуждали роль архитектора в принятии архитектурных решений.
Было высказано два тезиса:
1. Архитектор не принимает решения. Это делают менеджеры. Роль архитектора переоценена.
2. Архитектурные решения хорошо принимаются и без архитектора.
Позволил себе не согласиться )
1. То, что менеджерам кажется разумным и единственно верным решением - это то же решение принятое каким-то архитектором. Только чужим.
2. Если это решение стало популярным или даже необходимым, значит это кому-нибудь нужно. То есть кто-то с этого зарабатывает. Не вы.
3. Свой архитектор мог бы разработать альтернативное решение для своего бизнеса. Тут нужны навыки и опыт.
4. Свой архитектор может хотя бы сбалансировать интересы чужого и своего бизнеса.
5. Если вы ещё не почувствовали зачем вам нужен архитектор, то он вам и не нужен. Для архитектуры нужно созреть.
А в общем как и везде. Можем взять свое решение, но кто его будет делать. Или платить за чужое, но дорого, и результат непредсказуем.
#РольАрхитектора
👍4😁2
Obsidian
не реклама)
Хочу порекомендовать obsidian, как основной инструмент архитектора.
https://obsidian.md/
Я с большим удовольствием перенес в него:
1. Формирование ADR и RFC в формате md (до этого использовал intellij idea)
2. Захват интересного из Интернета (использовал Notion и Evernote)
3. Ведение заметок (использовал Evernote)
4. Записи в процессе проведения встреч (использовал Notepad++)
5. Подготовка кода для презентации (использовал разные утилиты и intellij idea)
6. Подготовку диаграмм в различных форматах (draw.io, excalidraw, plantUML)
7. Оформление и показ презентаций (использовал PowerPoint)
8. Управление списком дел (todoist)
Основной формат - md
Есть интеграция с Git
Есть мобильный клиент
Масса плагинов от комьюнити
Если интересно, как обустроил пространство под архитектуру, могу рассказать.
#АрхитектурныеИнструменты
не реклама)
Хочу порекомендовать obsidian, как основной инструмент архитектора.
https://obsidian.md/
Я с большим удовольствием перенес в него:
1. Формирование ADR и RFC в формате md (до этого использовал intellij idea)
2. Захват интересного из Интернета (использовал Notion и Evernote)
3. Ведение заметок (использовал Evernote)
4. Записи в процессе проведения встреч (использовал Notepad++)
5. Подготовка кода для презентации (использовал разные утилиты и intellij idea)
6. Подготовку диаграмм в различных форматах (draw.io, excalidraw, plantUML)
7. Оформление и показ презентаций (использовал PowerPoint)
8. Управление списком дел (todoist)
Основной формат - md
Есть интеграция с Git
Есть мобильный клиент
Масса плагинов от комьюнити
Если интересно, как обустроил пространство под архитектуру, могу рассказать.
#АрхитектурныеИнструменты
Obsidian
Obsidian - Sharpen your thinking
The free and flexible app for your private thoughts.
👍6🔥3
Две стадии развития системы
1. Черновик (прототип)
На этом этапе обкатываются интересные идеи. Втискиваются модные технологии.
Разработчики придумывают нестандартные ходы.
2. Чистовик (продукт)
На этом этапе система удовлетворяет потребности стейкхолдеров и приносит доход.
Переход от первой стадии ко второй часто происходит ВДРУГ.
Упс, наш прототип стал продуктом, и заявлено, что он умеет все, притом быстро и надёжно.
1. Черновик (прототип)
На этом этапе обкатываются интересные идеи. Втискиваются модные технологии.
Разработчики придумывают нестандартные ходы.
2. Чистовик (продукт)
На этом этапе система удовлетворяет потребности стейкхолдеров и приносит доход.
Переход от первой стадии ко второй часто происходит ВДРУГ.
Упс, наш прототип стал продуктом, и заявлено, что он умеет все, притом быстро и надёжно.
😁4
По посту выше.
Какой вариант Вы считаете оптимальным ?
Какой вариант Вы считаете оптимальным ?
Anonymous Poll
23%
1. Прототип уходит в прод и там постепенно доводится до продуктового состояния
23%
2. Стоит переписать прототип, формируя продукт с нуля, по другим (продуктовым) критериям
33%
3. На этапе прототипирования стоит закладывать "продуктовость"
3%
4. Свой вариант (в комментариях)
17%
5. Хочу просто посмотреть результат
Архитектура как код (AaC)
Сейчас многие говорят об AaC. Появляются продукты с поддержкой этой идеологии (например DocHub)
Я тоже задумался над вопросом, чего бы я, как ленивый архитектор, хотел бы получить от этой концепции.
Мой список:
1. Ведем модель как данные (архитектура как код) на основании которых можно автоматически сгенерировать любое требуемое представление
2. ADR - это commit в код архитектуры. Система должна помочь мне в формировании ADR исключив из процесса механическую составляющую (минимум - шаблонизатор)
3. Фиксация ADR приводит к автоматической интеграции новых решений в модель
4. Попытка зафиксировать ADR должна автоматически порождать задачу на проверку и согласование (RFC как merge request)
#AaC
Сейчас многие говорят об AaC. Появляются продукты с поддержкой этой идеологии (например DocHub)
Я тоже задумался над вопросом, чего бы я, как ленивый архитектор, хотел бы получить от этой концепции.
Мой список:
1. Ведем модель как данные (архитектура как код) на основании которых можно автоматически сгенерировать любое требуемое представление
2. ADR - это commit в код архитектуры. Система должна помочь мне в формировании ADR исключив из процесса механическую составляющую (минимум - шаблонизатор)
3. Фиксация ADR приводит к автоматической интеграции новых решений в модель
4. Попытка зафиксировать ADR должна автоматически порождать задачу на проверку и согласование (RFC как merge request)
#AaC
👍1
Автоматизация_архитектурного_процесса.png
163.1 KB
Автоматизация архитектурного процесса
Что лично я ожидаю от инструментов автоматизации архитектурного процесса.
Что лично я ожидаю от инструментов автоматизации архитектурного процесса.