Рубрика: Software architecture

Клиентский опыт и архитектурный стиль RESTful

Разговоры о Customer Experience (опыте клиентского взаимодействия) ведутся уже так долго, что вряд ли способны привлечь чьё-либо внимание. Особенно внимание айтишников. Мол, это вообще не к нам. Есть специально обученные люди – дизайнеры, которые всё сделают правильно и непременно улучшат этот самый клиентский опыт. Архитектурный стиль RESTful, описанный Роем Филдингом аж в 2000 году в диссертации Architectural Styles and the Design of Network-based Software Architectures, привлечет не большие внимание тех же самых айтишников. Всё  ведь и так понятно. JSON поверх HTTP  — вот и весь RESTful. Давайте все же разберемся, о чем этот архитектурный стиль и как он связан с опытом клиентского взаимодействия. Continue reading «Клиентский опыт и архитектурный стиль RESTful»

Реклама

Объясняем матрицу Захмана

Матрица Захмана, пожалуй, является наиболее ранним и наиболее показательным примером того, когда большая и сложная картинка скрывает суть вещей, которые она, по идее, должна пояснять. Помню своё первое знакомство с этим творением человеческой мысли. Если что-то и привлекает внимание при беглом взгляде на эту картинку, то это карта США в третьем верхнем квадрате, которая в более поздних версиях уступит вое место карте мира. Оторвав взгляд от тридцати разноцветных картинок, кое-где повторяющихся, можно заставить себя прочитать название столбцов и строк, приведенные, по традиции, очень мелким шрифтом. Если названия столбцов, содержащие слова «что», «где», «когда», еще пробуждают какие-то ассоциации, то названия строк: контекстуальный, концептуальный, логический, физический и уж совсем непонятно какой ассоциируются, разве что, с некоторыми уровнями абстракции. Думаю, на этом большинство зрителей этой картинки решают, что всё понятно и какого-либо более глубоко разбирательства просто не предпринимают. Но сегодня я хочу немного злоупотребить вашим вниманием и поговорить о матрице Захмана чуть подробнее. Continue reading «Объясняем матрицу Захмана»

Микросервисы в контексте корпоративной архитектуры

Обычно, чтоб убедить кого-нибудь в том, что микросервисная архитектура — это хорошо, её сравнивают с монолитом. Даже картинку специальную рисуют (см. ниже): с левой стороны база данных, сервер приложений и пользовательский интерфейс – это монолит(подразумеваем, что монолит — это плохо), а с правой стороны паутина фигурок и стрелочек между ними (типа, вот это хорошо). Не знают, убедит ли такая картинка случайного собеседника, но архитектор, будучи до конца честен сам с собой, должен сказать, что хорошо – это то что слева. И есть достаточное количество экспертов, которые критически восприняли идеи микросервисной архитектуры и постарались обратить наше внимание не только на достоинства, но и на недостатки такого подхода. Continue reading «Микросервисы в контексте корпоративной архитектуры»

Микросервисная архитектура и DevOps

В сентябре 2017-го вышла книжка Нила Форда, Ребекки Персонс и Патрика Куа Building Evolutionary Architectures. Я воспользовался ознакомительной подпиской  Safari Books чтоб полистать эту книжку и постараться разобраться с девятой, наиболее непонятной, характеристикой микросервисной архитектуры по Фаулеру и Льюису (см. Microservices a definition of this new architectural term). О том, чем занимается эта группа я писал уже в апреле прошлого года в заметке [r]evolutionary architecture, но на тот момент ознакомиться с позицией авторов можно было только видеозаписям пары выступлений, презентациям и подкастам. И вот теперь вышла книжка с системным изложением идей достаточно революционных, с одной стороны, и крайней прагматичных с другой. Но давайте обо всем по порядку. Continue reading «Микросервисная архитектура и DevOps»

Карты вашего кода

Саймон Браун сделал небольшую страницу: Модель С4 архитектуры программного обеспечения. Модель C4 была создана чтоб помочь командам разработчиков программного обеспечения описывать и обсуждать архитектуру решений. Её можно использовать как во время начальных сессий проектирования, так и при ретроспективе существующих решений. Это способ создания карт вашего кода на разных уровнях детализации.

Модель C4 рассматривает статические структуры программной системы и включает четыре типа основных диаграмм: системный контекст (пользователи и внешние приложения), контейнеры (основные подсистемы), компоненты и классы. Об использовании дополнительных диаграмм, моделировании микросервисов, отношении C4 model с другими нотациями моделирования и инструментах создания диаграмм см. оригинальную страницу C4model

Управление портфелем ИТ проектов

На недавнем вебинаре: ИТ-архитектура и управление изменениями. Обновление процесса CHG мы рассматривали процесс изнутри. Надеюсь, что это было полезным и содержательным. Однако взгляд с такой точки зрения сопровождается одним допущением – запросы на изменения поступают к нам из внешней среды случайным образом и в случайные моменты времени. Безусловно, это не так и в реальной жизни мы знаем о количестве и содержании будущих запросов на изменения немного больше, чем ничего. Особенно если наши бизнес-заказчики ведут плановое хозяйство, собирают свои пожелания на следующий год как-то устанавливают их приоритеты, классифицируют изменения, отделяют главное от самого главного, важное от срочного, появление новых продуктов от улучшения существующих. Continue reading «Управление портфелем ИТ проектов»

Когнитивные карты

В 1948 году Эдвард Чейс Толмен опубликовал статью «Когнитивные карты у крыс и людей», ставшую в дальнейшем широко известной и послужившую одним из триггеров того, что мы сегодня называем когнитивные науки. (Изложение статьи на русском см. Толмен Э. Когнитивные карты…  ) В ней он рассказывает о нескольких экспериментах с крысами, один из которых выглядел следующим образом. Крысам (хотел написать предлагали, но думаю, что здесь будет более уместно другое слово), так вот большая группа крыс наблюдалась в процессе освоения лабиринта, состоящего из 14 Т-образных коридоров. Сначала в эксперименте участвовали две контрольные группы – одна, которая никогда не находила пищу в лабиринте(I) и другая, которая её получала на протяжении всего эксперимента (II). Естественно, что участники второй группы предпочитали двигаться к выходу из лабиринта, т.к. в нем была расположена пища (вероятно сыр). С каждым днем участники этой группы совершала все меньшее и меньшее количество ошибок(см. рисунок ниже). У группы номер один мотивации искать выход из лабиринта не было, и они степенно блуждали по лабиринту, иногда находя выход.  Однако, самое интересное началось после выделения в эксперименте еще одной группы (III) Continue reading «Когнитивные карты»