За что не любят архитекторов предприятия

Иногда я буду делать небольшие критические обзоры текстов разных авторов. Сегодня мне попалась заметка David R Oliver C4+1 — The Services Layer. В статье много есть к чему придраться, но я постараюсь только по существу. Читать далее За что не любят архитекторов предприятия

Слоёный пирог стейкхолдеров

Многотомник текущей (десятой) версии фреймворка корпоративной архитектуры TOGAF содержит много советов по работе c заинтересованными лицами (stakeholders). А нотация описания архитектуры предприятия Archimate включает в себя довольно развесистый набор концепции для описания целей, оценок, движущих сил, ограничений и требований этих самых стейкхолдеров. Но все же, я думаю, что ряд довольно важных вещей, касающихся восприятия и взаимодействия с заинтересованными лицами, остался невысказанными. Они либо вообще не добрались до текста стандарта, либо запутались где-то между строк. Давайте о них сегодня поговорим Читать далее Слоёный пирог стейкхолдеров

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

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

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

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

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

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

Модели корпоративной архитектуры. TOGAF10 и Archimate3.2

https://www.youtube.com/live/oRy6lhIvHcU?si=HyPzC4jP7FZKpYLD

Развилки архитектурных решений (пример)

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

Solution architect Семён получил новую задачку: расширить функционал простенького сервиса обработки заявок. Ничем не примечательный сервис предоставляет HTTP API, с коллекцией request, в которую можно опубликовать заявку. Проведя пару проверок и обогатив заявку данными из внешних систем, сервис отправляет заявку в очередь сообщений. Семён недавно работает в компании и хотя, по его мнению, задачка довольно простая, решает посоветоваться с Enterprise architect-ом Евгением. Тем более, что на днях Евгений собрал всех solution-ов и рассказал им о записях архитектурных решений (architecture decision record). Теперь каждый архитектор должен не только набросать небольшой эскиз, но и выложить набор решений в виде adr-файлов в версионное хранилище. Читать далее Развилки архитектурных решений (пример)

Теория когнитивной нагрузки и архитектура предприятия

Теория когнитивной нагрузки (Cognitive load theory) Джона Свеллера, популяризированная в мире ИТ книжкой про командные топологии, не только и не столько о том, как правильно выстроить обучение и не перегрузить людей избыточной информацией. Рассуждения о том, что способствует обучению, а что мешает, безусловно, важны, но начинается теория когнитивной нагрузки с описания некоторой (путь и крайне простой) модели организации памяти. В ней память человека делится на рабочую, используемую в данный конкретный момент и отвечающую за обработку информации для текущего действия, и долгосрочную, которая хранит уже имеющуюся информацию и обогащает ей новыми знаниями. Читать далее Теория когнитивной нагрузки и архитектура предприятия

Platform Engineering. Архитектура цифровой платформы

Обсуждаем модный термин #PlatformEngineering. Пытаемся понять о чем речь:

  1. Правда ли, что Platform Engineering это для тех, у кого не все получилось с DevOps
  2. Или же это про внутреннюю платформу разработки (Internal Developer Platforms, IDPs). Что-то похожее на https://backstage.io/ от Spotify
  3. А может портал разработчика это только дверь, а платформой является все то, что скрывается за этой дверь. Похоже на холст с очагом, не правда ли?
  4. Причем здесь решения от Cloud Native Computing Foundation (CNCF) и правда ли с ними так много проблем, как об этом недавно написал Сэм Ньюман? 5. Как не влипнуть в очередной бестолковый проект и увидеть в платформе ценность

Слайды: telegram-канал Архитектура ИТ-решений

Ссылки:

  1. Getting started with Team Topologies — infographic
  2. Platform Engineering 101
  3. What I Talk About When I Talk About Platforms
  4. Digital Platform Strategy 
  5. The State of DevOps Report 2020. Internal Platforms & Change Management
  6. Backstage System Model
  7. Open Application Model
  8. Team Cognitive Load. By Matthew Skelton, Manuel Pais

 

The Business Analysis Standard

Международный институт бизнес-анализа IIBA в ноябре прошлого года выпустил новую книжку The Business Analysis Standard (Загрузить его можно с сайте IIBA https://go.iiba.org/The-Standard)

Краткий обзор, видеоролик и ответы на основные вопросы можно посмотреть по этой ссылке 

Изменения в стандартах 420×0

Долгое время единственным ISO-шным стандартом по архитектуре оставался ISO/IEC/IEEE 42010:2011 Systems and software engineering — Architecture description. Он даже был переведен в 2016 году на русский язык и выпущен как ГОСТ Р 57100 Системная и программная инженерия. Описание архитектуры. Переведен он был не очень хорошо, но предоставлял основания использования подходов из международного стандарта 42010.

В 2019 году появились сразу два новых архитектурных стандарта 42020 и 42030 (Architecture processes и Architecture evaluation framework). Про двадцатый стандарт я обязательно напишу более подробно в одном из следующих сообщений. Как выглядит архитектурный процесс и как он вписывается в другие активности и виды деятельности – вопрос важный. Но здесь я в большей мере хочу акцентироваться на влияние двух этих стандартов на 42010. Этот стандарт тоже обновился в ноябре прошлого, 2022 года. (ссылка на актуальную версию) Читать далее Изменения в стандартах 420×0