Разговоры о Customer Experience (опыте клиентского взаимодействия) ведутся уже так долго, что вряд ли способны привлечь чьё-либо внимание. Особенно внимание айтишников. Мол, это вообще не к нам. Есть специально обученные люди – дизайнеры, которые всё сделают правильно и непременно улучшат этот самый клиентский опыт. Архитектурный стиль RESTful, описанный Роем Филдингом аж в 2000 году в диссертации Architectural Styles and the Design of Network-based Software Architectures, привлечет не большие внимание тех же самых айтишников. Всё ведь и так понятно. JSON поверх HTTP — вот и весь RESTful. Давайте все же разберемся, о чем этот архитектурный стиль и как он связан с опытом клиентского взаимодействия. Читать далее Клиентский опыт и архитектурный стиль RESTful
Рубрика: Software architecture
Объясняем матрицу Захмана
Матрица Захмана, пожалуй, является наиболее ранним и наиболее показательным примером того, когда большая и сложная картинка скрывает суть вещей, которые она, по идее, должна пояснять. Помню своё первое знакомство с этим творением человеческой мысли. Если что-то и привлекает внимание при беглом взгляде на эту картинку, то это карта США в третьем верхнем квадрате, которая в более поздних версиях уступит вое место карте мира. Оторвав взгляд от тридцати разноцветных картинок, кое-где повторяющихся, можно заставить себя прочитать название столбцов и строк, приведенные, по традиции, очень мелким шрифтом. Если названия столбцов, содержащие слова «что», «где», «когда», еще пробуждают какие-то ассоциации, то названия строк: контекстуальный, концептуальный, логический, физический и уж совсем непонятно какой ассоциируются, разве что, с некоторыми уровнями абстракции. Думаю, на этом большинство зрителей этой картинки решают, что всё понятно и какого-либо более глубоко разбирательства просто не предпринимают. Но сегодня я хочу немного злоупотребить вашим вниманием и поговорить о матрице Захмана чуть подробнее.
Читать далее Объясняем матрицу ЗахманаМикросервисы в контексте корпоративной архитектуры
Обычно, чтоб убедить кого-нибудь в том, что микросервисная архитектура — это хорошо, её сравнивают с монолитом. Даже картинку специальную рисуют (см. ниже): с левой стороны база данных, сервер приложений и пользовательский интерфейс – это монолит(подразумеваем, что монолит — это плохо), а с правой стороны паутина фигурок и стрелочек между ними (типа, вот это хорошо). Не знают, убедит ли такая картинка случайного собеседника, но архитектор, будучи до конца честен сам с собой, должен сказать, что хорошо – это то что слева. И есть достаточное количество экспертов, которые критически восприняли идеи микросервисной архитектуры и постарались обратить наше внимание не только на достоинства, но и на недостатки такого подхода. Читать далее Микросервисы в контексте корпоративной архитектуры
Микросервисная архитектура и DevOps
В сентябре 2017-го вышла книжка Нила Форда, Ребекки Персонс и Патрика Куа Building Evolutionary Architectures. Я воспользовался ознакомительной подпиской Safari Books чтоб полистать эту книжку и постараться разобраться с девятой, наиболее непонятной, характеристикой микросервисной архитектуры по Фаулеру и Льюису (см. Microservices a definition of this new architectural term). О том, чем занимается эта группа я писал уже в апреле прошлого года в заметке [r]evolutionary architecture, но на тот момент ознакомиться с позицией авторов можно было только видеозаписям пары выступлений, презентациям и подкастам. И вот теперь вышла книжка с системным изложением идей достаточно революционных, с одной стороны, и крайней прагматичных с другой. Но давайте обо всем по порядку. Читать далее Микросервисная архитектура и DevOps
Карты вашего кода
Саймон Браун сделал небольшую страницу: Модель С4 архитектуры программного обеспечения. Модель C4 была создана чтоб помочь командам разработчиков программного обеспечения описывать и обсуждать архитектуру решений. Её можно использовать как во время начальных сессий проектирования, так и при ретроспективе существующих решений. Это способ создания карт вашего кода на разных уровнях детализации.
Модель C4 рассматривает статические структуры программной системы и включает четыре типа основных диаграмм: системный контекст (пользователи и внешние приложения), контейнеры (основные подсистемы), компоненты и классы. Об использовании дополнительных диаграмм, моделировании микросервисов, отношении C4 model с другими нотациями моделирования и инструментах создания диаграмм см. оригинальную страницу C4model
Управление портфелем ИТ проектов
На недавнем вебинаре: ИТ-архитектура и управление изменениями. Обновление процесса CHG мы рассматривали процесс изнутри. Надеюсь, что это было полезным и содержательным. Однако взгляд с такой точки зрения сопровождается одним допущением – запросы на изменения поступают к нам из внешней среды случайным образом и в случайные моменты времени. Безусловно, это не так и в реальной жизни мы знаем о количестве и содержании будущих запросов на изменения немного больше, чем ничего. Особенно если наши бизнес-заказчики ведут плановое хозяйство, собирают свои пожелания на следующий год как-то устанавливают их приоритеты, классифицируют изменения, отделяют главное от самого главного, важное от срочного, появление новых продуктов от улучшения существующих. Читать далее Управление портфелем ИТ проектов
Когнитивные карты
В 1948 году Эдвард Чейс Толмен опубликовал статью «Когнитивные карты у крыс и людей», ставшую в дальнейшем широко известной и послужившую одним из триггеров того, что мы сегодня называем когнитивные науки. (Изложение статьи на русском см. Толмен Э. Когнитивные карты… ) В ней он рассказывает о нескольких экспериментах с крысами, один из которых выглядел следующим образом. Крысам (хотел написать предлагали, но думаю, что здесь будет более уместно другое слово), так вот большая группа крыс наблюдалась в процессе освоения лабиринта, состоящего из 14 Т-образных коридоров. Сначала в эксперименте участвовали две контрольные группы – одна, которая никогда не находила пищу в лабиринте(I) и другая, которая её получала на протяжении всего эксперимента (II). Естественно, что участники второй группы предпочитали двигаться к выходу из лабиринта, т.к. в нем была расположена пища (вероятно сыр). С каждым днем участники этой группы совершала все меньшее и меньшее количество ошибок(см. рисунок ниже). У группы номер один мотивации искать выход из лабиринта не было, и они степенно блуждали по лабиринту, иногда находя выход. Однако, самое интересное началось после выделения в эксперименте еще одной группы (III) Читать далее Когнитивные карты
Несколько замечаний о корпоративной архитектуре
По примеру старших товарищей я решил сделать в блоге обновляемое сообщение. Я периодически буду возвращаться к этой заметке, что-то добавлять, что-то вычеркивать, а еще что-то переписывать заново. Если изменения будут существенными, то я стану поднимать это сообщение вверх и повторно размещать ссылку на него в соц.сетях и не буду этого делать при незначительных изменениях. Тема, о которой пойдет речь, может быть озаглавлена «Роль ИТ-архитектора в организации», как это было сделано в одной из презентаций (см. https://www.slideshare.net/MxSmirnov/ss-31232067) или Когда, кому и зачем нужна Архитектура Предприятия, как в одноименном из сообщений этого блога. Читать далее Несколько замечаний о корпоративной архитектуре
ГОСТ Р 57100. Системная и программная инженерия. Описание архитектуры
В прошлом году федеральное агентство по техническому регулированию и метрологии утвердило национальный стандарт: ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 «Системная и программная инженерия. Описание архитектуры», идентичный международному стандарту ISO/IEC/IEEE 42010:2011 «Системная и программная инженерия. Описание архитектуры» (конец цитаты). Но, утвердило оно его не просто так, а с датой ввода в действие 1 сентября 2017 года. Наверное, утверждение стандарта с отложенной датой ввода в действие является общепринятой практикой, но для ГОСТ Р 57100 это, безусловно, имело особый смысл Читать далее ГОСТ Р 57100. Системная и программная инженерия. Описание архитектуры
HATEOAS: реализация функций в RESTful API
Я не знаю кто и когда придумал аббревиатуру HATEOAS, означающую Hypermedia As The Engine Of Application State. Выглядит она страшно, а звучит непонятно. В общем разбираться с тем что это такое и зачем оно нужно совершенно не хочется. Из-за этого потенциал, заложенный в архитектурный стиль REST и позволяющий создавать довольно интересные программные интерфейсы остается не раскрытым. Но обо всем по порядку. Читать далее HATEOAS: реализация функций в RESTful API