Практика архитектуры предприятия убирает технологические барьеры развития бизнеса

Смысл текста в одной картинке:

Бурное развитие ИТ-систем, объединений и поглощений в 1980-х привело к тому, что к 1990-м компании разделились на две группы. Первая группа погрязла в зоопарке несовместимых систем, из-за которого они не могли двигаться дальше, т. к. любое серьезное бизнес решение блокировалось невозможностью технологических изменений. Вторая группа смогла справиться с изобилием технических решений и продолжала менять стратегию и приспосабливаться под меняющуюся рыночную, социальную и законодательную обстановку. Руководители и собственники заинтересовались, что же такого делали компании из второй группы, и оказалось, что они делали примерно одно и то же. В своих бизнес-решениях они учитывали необходимые изменения ИТ-систем и в результате у них не было критического расхождения между структурой бизнеса и структурой ИТ-ландшафта. Практику принятия бизнес-решений с учетом текущего и планируемого технологического ландшафта назвали архитектурой предприятия, а технических директоров включили в круг основных лиц, принимающих решения, потому что финансистов, коммерсантов и юристов было уже недостаточно для того, чтобы принимать дальновидные решения. Эскизы архитектуры предприятия и пояснительные записки по планам развития ИТ-ландшафта в их связи со стратегическими планами заняли свое место на столах руководства и время на совещаниях. Технический директор и архитекторы предприятия стали тем мостиком, который связал отделы разработки программного обеспечения и управления инфраструктурой с бизнес-функциями.
И тут возникла вторая проблема - при переходе руководителей или инженеров из одной компании в другую, они больше не могли выполнять свою работу. Язык для разговора об ИТ-системах и методы координации ИТ и бизнеса был везде разный. Настало время стандартизации, и языки описания архитектуры (ADL, architecture description languages) распались на три группы. Неформальные, до сих широко распространенные в России, строго формальные, из которых в реальном применении не выжил не один стандарт, и языки архитектурных описаний, основанные на UML. Справедливости ради стоит сказать, что некоторые крупные предприятия успешно используют строго формальные языки описания для создания цифровых двойников предприятия, см., например, случай Домодедово, но разрабатывают их строго под свои нужды, не используя стандарты, а подготовка операторов такой системы занимает тысячи часов. Основные инвестиции и успехи последних 8 лет связаны с языками, основанными на UML. Я использую ArchiMate, но легко могу перейти на другие нотации, например AADL, SysML, ADML, в основе любого из них лежит тот или иной вариант системного подхода, меняется только набор концептов и отношений, логика построения модели.
Так стоит ли тратить время на изучение архитектуры предприятия? Да, это имеет смысл, потому что:
- из сотен стандартов и языков остался десяток документов и спецификаций, уже не первых редакций, с известными сценариями применения;
- эти стандарты и спецификации поддержаны бесплатными и платными инструментами, сообществами и руководствами, которые позволят быстро подобрать и поставить подходящую практику;
- специалисты ведут регулярную работу по гармонизации и совместному использованию стандартов и спецификаций;
-  многие методы разбиты на отдельные приемы моделирования, которые можно освоить за полчаса, и решить конкретную задачу.
На эту тему есть множество текстов, блогов и видеоуроков, и при необходимости можно самостоятельно во всем разобраться. Единственным серьезным препятствием на этом пути является терминологическая путаница и нечеткость понятий. Этот текст наводит базовый порядок с понятиями, которые необходимы для дальнейшего изучения темы.

Центральным понятием является концепция системы как какой физически существующей, реальной вещи, которая выполняет заданную функцию. У системы есть архитектура, архитектура реальна, ее могут воспринять разные люди. Например, мы смотрим на здание и понимаем, какой у него архитектурный стиль - модерн, скандинавский стиль или готика. Если мы увидим эскиз готического собора или его фотографию, то мы скажем: "Это готическая архитектура". Но это неточное выражение, на самом деле мы имели в виду: "Реальное здание, которое выглядит как этот эскиз или здание на фотографии, имеет готическую архитектуру". Поэтому важно различать описание архитектуры и саму архитектуру. 
Можно рассматривать предприятие как особый вид системы - систему систем. Система имеет владельца, который может отдать приказ на ее создание или изменение, а система систем состоит из отдельных систем, у каждой из которых свой владелец. В результате нет такого человека, который бы смог отдать приказ на ее изменение, владельцы отдельных систем, из которых состоит система систем, вынуждены договариваться и координировать свои действия. При этом система систем имеет свою отдельную функцию, которая отличается от входящих в нее систем. Типичный пример системы систем - это город. Он состоит из транспортной системы, инфраструктуры, систем связи, систем жилых и коммерческих объектов капитального строительства, предприятий и организаций, и многих других систем со своими функциями. Совместно они обеспечивают функцию обеспечения совместного проживания и деятельности для тысяч и миллионов людей, чего не может обеспечить ни одна из входящих в город систем. При этом у больницы свой владелец - муниципалитет, а у публичной компании сотовой связи свой - акционеры, и чтобы поставить вышку сотовой связи на территории больницы, эти владельцы должны договориться, компания не может самовольно выполнить такой проект. У систем систем тоже есть архитектура, у города есть фундаментальное устройство. Например, древние Афины были устроены вокруг полиса, средневековый город вокруг замка, современные города могу быть агломерациями, мегаполисами, а вы легко отличите европейский квартал во Владивостоке от советской застройки. И это касается не только внешнего облика и архитектуры зданий, в архитектуру города входит количество и расположение парков, устройство дорожной сети и путепроводов, водопровод и электрические сети, и множество других необходимых для работы и развития города систем. Хорошая архитектура позволяет городу успешно развиваться, неудачная блокирует пути улучшения или делает их запредельно дорогими. Также и у предприятия есть архитектура. Вы возразите, что у предприятия есть один владелец и он может отдать приказ на изменение предприятия, поэтому предприятие не является системой систем. Для микропредприятий без партнеров это замечание будет справедливо, и хотя пекарню, в которой работают отец и сын можно рассматривать как систему и говорить, что у нее есть архитектура предприятия, но такой пример не будет иметь никакого иного смысла, кроме учебного. С ростом предприятия, примерно с 25 человек, его деятельность перестает полностью помещаться в голове владельца, и он делегирует управление отдельными частями предприятия, организациями, другим людям. Например, в булочной, даже состоящей из двух человек, с самого начала есть три организации - закупочная, которая выполняет функцию обеспечения сырьем, производственная, которая занимается изготовлением продукции, и торговая, которая обеспечивает сбыт изготовленной продукции. Если булочная успешна, то владелец может нанять отдельных людей, которые будут заниматься закупками, производством и торговлей, а сам он будет владельцем. При этом он отдает им полномочия, которые необходимы для того, чтобы организации выполняли свои функции, и начинает спрашивать за их исполнение. Тут-то и возникает система систем. При том, что владелец булочной может уволить любого из работников и назначить нового, он не до конца понимает, как устроено его предприятие, как конкретно работает организация закупок или производство, поэтому если начальник производства говорит ему, что вот так-то сделать нельзя, владелец организации вынужден с ним договариваться. В противном случае это не делегирование, а предприятие не организовано, а управляется  распоряжениями по месту. Тем более это справедливо для концерна, который состоит из множества даже юридически независимых лиц. Так что предприятие — это система систем и у нее есть архитектура.
Эта архитектура может быть описана, например, органиграммой, уставом предприятия, картой бизнес-процессов, политиками и процедурами, настройкой параметров ERP и CRM, дизайном досок канбан, схемой неформальных связей участников и владельцев предприятия и множеством других способов. Эти описания в какой-то мере отражают реальность и описывают архитектуру предприятия, но самой архитектурой не являются. Архитектура, напомню, реальна. И тут есть распространенная ошибка. У программ и предприятий, в отличие от зданий, архитектура не видна. Ее можно выявить, увидев, как работает программа, или как функционирует предприятие, но нельзя понять, просто окинув взглядом комнату, где сидит 30 программистов. Поэтому те, кто видят архитектуру предприятия, глядя на работу людей, их называют архитекторами предприятия, записывают свое видение в виде описания архитектуры предприятия. И зачастую такой документ, который описывает архитектуру предприятия, тоже называют "архитектурой предприятия". Поэтому лучше выражаться четко, а других людей проверять, что они имеют в виду - реально существующую архитектуру реального предприятия как системы систем или описание этой архитектуры.
Помните, я говорил про языки описания архитектуры? В них есть подгруппа языков описания архитектуры предприятия. Самый старый и известный из них — это семейство IDEF. Бизнес-процессы часто описывают с помощью BPMN с его расширениями CMMN и DMN. В программном пакете ARIS есть свои нотации, например EPC. Есть еще SoaML, AADL, я пользуюсь ArchiMate 3.0. Он хорошо гармонизирован с семейством BPMN, подходит для описания как системной архитектуру, так и архитектуры предприятия, и диаграммы ArchiMate легко понятны даже неспециалистам. ArchiMate 3.0 — это спецификация языка, документ, который описывает логику создания моделей. Есть бесплатный инструмент с открытым кодом, который позволяет легко создавать модели ArchiMate.
Ошибка, которую допускают, когда описание архитектуры предприятия называют архитектурой предприятия, переносится и на модели ArchiMate. Часто модель, созданную в редакторе диаграмм, тоже называют архитектурой предприятия, хотя это всего лишь описание, причем не единственное. С описанием архитектуры предприятия все вообще сложно. В программных и "железных" системах архитектуру можно описать точно, вплоть до генерации из модели физического изделия, как, например, происходит при разработке и производстве микросхем. Чтобы точно описать архитектуру предприятия, надо потратить настолько много сил и времени, что эта работа будет оправдана только если это сложное и большое предприятие с высокой ценой ошибки при принятии решений. Поэтому такое формальное моделирование есть в армии, на флоте, в нефтедобыче и нефтехимии, а сейчас еще появляется в крупном капитальном строительстве. Но в общем случае наиболее рациональным подходом является составление высокоуровневой модели архитектуры предприятия в ArchiMate, которая описывает достаточно стабильные инварианты, а в свойствах элементов этой модели ссылаться на базы данных и документы, которые описывают текущее состояние предприятия и детальные планы по развитию его отдельных частей. Если дать метафору, то модель архитектуры предприятия в ArchiMate - это карта 1:50,000, по которой только можно понять, в каком квадрате мы сейчас находимся, что в целом там есть и у кого спрашивать про детальное расположение и специфику. Т.е., модель архитектуры предприятия не столько описывает архитектуру, сколько служит каталогом других документов, баз данных, моделей и других рабочих продуктов, которые и описывают архитектуру предприятия. В таком случае модель архитектуры предприятия служит для координации многочисленных участников проектов организационных изменений, то, что в англоязычной литературе называется communication vehicle, средство координации. При таком подходе описание архитектуры предприятия состоит из:
- модели архитектуры предприятия;
- обоснования архитектуры предприятия;
- описания модели перехода, описание портфеля стратегических проектов;
- пояснительной записки к архитектуре предприятия, т.н. архитектурного эссе.
Другими словами, когда говорят, что ArchiMate — это такой язык описания архитектуры предприятия, а сама модель, созданная с использованием спецификации ArchiMate, это архитектура предприятия, допускают две ошибки:
- модель, созданная с помощью редактора, который поддерживает спецификацию ArchiMate, является всего лишь частью описания архитектуры предприятия, и не имеет смысла без пояснительной записки, заполненной модели атрибутов, и соглашения о моделировании;
- модель, созданная с помощью редактора, который поддерживает спецификацию ArchiMate, содержит не только описание самой архитектуры предприятия, в ней также записана стратегия предприятия и план портфеля стратегических проектов, без этих данных модель тоже почти бессмысленна.
Зачем вообще нужен редактор диаграмм, поддерживающий спецификацию ArchiMate? Есть множество других инструментов, в которых вы уже работаете, а уж система управления графовыми базами данных типа neo4j вообще делает все то же самое, но быстрее, качественнее, с большим количеством отчетов и другими полезными функциями? Еще раз повторюсь, что наиболее распространенным сценарием успешной работы с архитектурными языками является использование моделей описаний архитектуры в качестве каталога. Пример связи модели в ArchiMate с neo4j. Архитектурный язык сильно ограничивает выразительные средства, он задает очень ограниченный набор объектов и отношений для модели. Вот пример метамодели, которую использую я:

Вот пример метамодели, которую использует Intel:

Как видите, эти метамодели компактные, их легко понять, легко читать и из них легко сделать шпаргалки на 1 страницу, чтобы модели могли читать и поддерживать в своей части даже неспециалисты.
Правда, у такой простоты есть оборотная сторона - такие диаграммы сами по себе крайне неточны, поэтому соглашение по моделированию состоит не только из метамодели описания архитектуры предприятия, но и из:
- свойств элементов метамодели архитектуры предприятия;

- паттернов моделирования архитектуры предприятия, целое руководство есть в учебнике Mastering ArchiMate by Gerben Wierda;
- стилей моделирования;
- формата архитектурного эссе либо пояснительной записки к архитектуре предприятия.

Если свести смысл этого текста к одной картинке, то вот она:

Теперь у вас есть понимание основных концептов этой предметной области и вы можете изучать источники и разбираться самостоятельно.