Архитектура данных в архитектуре решений

Накануне, в ходе стрима о Solution Architecture, я отвечал на вопрос: насколько востребованным для архитектора решений является описание потоков данных в DWH. Должен ли он этим заниматься и есть смысл вкладываться в это направление.  (Запись всего стрима здесь: https://youtube.com/live/_GKNhoPmZYI ) Я воспользовался картинкой из книжки Alan McSweeney Introduction to Solution Architecture в которой довольно много чего написано про данные в архитектуре решений и задачи, связанные с интеграцией данных.

Картинка выше (надеюсь, цитируя её, я не нарушаю авторских прав) иллюстрирует тот очевидный факт, что дизайн любого решение включает в себя ландшафт данных. Такой ландшафт описывает как данные создаются, собираются, передаются, обрабатываются, хранятся, используются и, в конечном счете, уничтожаются. Причем, в каждом конкретном решении могут быть задействованы существующие приложения или же потребоваться разработка новых средств работы с данными. А еще сами данные могут быть довольно разными по своей природе: документы и контент, следы операций в виде событий, основные и справочные данные.

Чуть ниже автор сетует, что возможно его способ представления выглядит несколько запутанным и слегка неуклюжим, но в оправдание замечает, что в реальных проектах приходится сталкиваться с не менее сложными проблемы в части извлечения и обработки данных.

Все это именно так и, конечно, если вам интересно, то конечно обратитесь к соответствующей главе в первоисточнике. Но уже отвечая на вопрос я вспомнил, что в самом начале года Alan McSweeney опубликовал большой набор слайдов Data Architecture For Solutions Я обещал поделиться ссылкой на него, что сейчас и делаю

Увлекательного изучения!

SAFe, LeSS, O-AA / Практики корпоративного архитектора

Продолжение ответов на вопросы с предновогоднего вебинара

UML Шрёдингера

uml2

По интернетам несколько месяцев бродит в оригинале и переводах статья Ernesto Garbarino Has UML Died Without Anyone Noticing? Слушатели предстоящего вебинара Грамматика системных моделей попросили меня поделиться собственным мнением о том, что же произошло с UML. Я решил разобрать статью целиком и сделаю это по переводу UML умер, а никто и не заметил?

Читать далее UML Шрёдингера

Воронка инициатив

Я часто рассказываю о том, что наибольшую ценность архитектор ИТ-решений приносит не ответом на вопрос как? реализовать ту или иную задачу, а отвечая на вопрос что? делать в первую очередь, что во вторую, а что пока не делать вовсе. Но в этом блоге так и нет внятной записи, рассказывающей о воронке инициатив, её этапах, правилах отсева идей и действиях, которые архитектор, аналитик и другие заинтересованные лица должны осуществить.

Читать далее Воронка инициатив

Коротко об обучении ИТ-архитекторов

Сейчас в образовании популярна новая тема: обучение через большие идеи или дидактика «больших идей». Не знаю, как скоро этот подход проникнет в среднее образование, но для своих курсов по ИТ-архитектуре я нашел его, как говорится методом проб и ошибок. Ну, например, архитектуру ИТ-решений (solution architecture) и микросервисы можно изучать отдельно. Хотя изучать просто ИТ-архитектуру немного скучно. А изучать микросервисную архитектуру, особенно после большого и долгого хайпа, довольно сложно. Все, вроде бы, и так всё уже об этом знают. Ну, может быть, в общих чертах и недостаточно глубоко. Хотя буквально в каждой группе, первая же из девяти характеристик микросервисной архитектуры по Льюису-Фаулеру оказывает сюрпризом хотя бы для одного из слушателей. А вот изучать и то и другое одновременно полезно и с точки зрения поддержания интереса, и для приобретения конкретных компетентностей. Читать далее Коротко об обучении ИТ-архитекторов

Архитектура как код

Следующая большая вещь (next big thing) в ИТ-архитектуре, безусловно, заключается во встраивании создания и тестирования архитектурных артефактов (описаний, моделей и пр.) в CI/CD pipeline. Идея эта не особо оригинальная. В интернет можно найти множество материалов с заголовком непрерывная архитектура (Continuous Architecture) или Architecture as a Code но в большинстве из них речь идет о чем-то другом (см., например: https://pgppgp.wordpress.com/).  Пожалуй, только у Саймона Брауна звучит эта тема (см. Software architecture as code ), но в большей степени фоном для C4model. Одним словом, архитекторы по-прежнему полагают, что кто-то будет будем им рисовать и обновлять архитектурные описания повинуясь зову сердца и чувству долга. Читать далее Архитектура как код

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

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

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

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

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

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

Карта ИТ ландшафта

landscapemapЕсли вы зайдете в офис средней или крупной организации, поймаете в коридоре сотрудника и спросите у него: «Чем в вашей компании занимаются ИТ-архитекторы», то вряд ли услышите в ответ: «Как чем? Они моделируют структуру и поведение информационных систем; с различных точек зрений отображают их текущее и целевое состояние, формулируют фундаментальные принципы организации корпоративной информационной системы для принятия ключевых решений…». Вероятность такого события существуют, но она совсем небольшая. Если же ваш собеседник произнесет такие или похожие слова, то значит случилось маловероятное событие и вы поймали в коридоре именно ИТ-архитектора. Скорее всего этого не произойдет. Ваш собеседник на некоторое время задумается, но возможно вспомнит, что есть в ИТ такой парень, которого называют архитектором. И еще, что он рисует какую-то большую не очень внятную картинку и с умным видом произносит загадочные слова. Впрочем, айтишники они все такие… Читать далее Карта ИТ ландшафта

Рефрейминг архитектуры предприятия

Hands Framing House Drawing and Photo Combination on White.Еще один гартнеровский отчет 2016 года, который я хотел бы упомянуть называется Rethink EA as an Internal Management Consultancy to Rapidly Deliver Business Outcomes (9 June 2016, G00291300). Если вы не являетесь подписчиком, то посмотрите вебинар: Marcus Blosch. Enterprise Architecture as Management Consultancy. Данный материал полезней рассматривать как постановку проблемы, а не как рецепт решения (рецепты у Gartner называются словом Toolkit). Экспозицию статьи можно представить одной цитатой:

At a recent CIO event, several CIOs happily explained that they had no enterprise architecture and saw no value in it. They felt rigid architectures, too many policies and standards, and heavy-handed oversight had slowed down innovation. They believed EA was incompatible with the digital world of continuous innovation and delivery. However, despite being free of EA, these CIOs had mixed success with their efforts at digital innovation.

A small number of CIOs had reframed EA as a form of internal management consulting focused on delivering innovation and change.

Читать далее Рефрейминг архитектуры предприятия