Об архитектурные языки и подходы к архитектурным описаниям
1. Поскольку я консультант, то мне постоянно приходится разбираться с целевой системой (в том числе -- организационной системой) на начальных стадиях её жизненного цикла, когда никто ещё ничего не понимает про будущую систему -- т.е. когда еще непонятно, что нужно делать (наличествует Ситуация), какие методы для этих действий использовать. В этот момент ранних стадий жизненного цикла требуется подробное одновременное разбирательство с функциональными требованиями и поддерживающей эти непрерывно уточняемые требования архитектурой. Соответственно, нужно наличие хорошей библиотеки компонент методов инженерии требований и инженерии системной архитектуры и наличие развернутой технологии подобной работой (наличие освоивших эти дисциплины людей и наличие инструментария).
2. Лучшим на сегодня мне известным способом быстро обеспечить архитектурное описание, равно как и зафиксировать требования, является малевание от руки простых диаграммок фломастером на флипчарте (архитектурное описание, с приписанными там да сям отдельными словами, обозначающими требования), сопровождаемые словами из разных статей, учебников и прошлых жизненных ситуаций (ситуационный метод, вытаскиваемый из библиотеки компонент метода -- прямо из головы).
Хихикну в сторону, что аналитические диаграммы ISO 15926 во всём мире сейчас тоже рисуют карандашом на бумажке, в крайнем случае -- в PowerPoint, Word или Visio. Сапожники, как водится, без сапог: кто предлагает универсальные языки описания всего, читаемые машиной, сам остаётся без такого языка.
Итого: технологии по факту нет -- дисциплина не описана, и передаётся исключительно изустно, язык описания требований и архитектуры неформален, инструменты времён изобретения доски с мелом. Самый современный инструмент -- это телефон, на который фотографируют флипчарт.
3. С флипчартом (а иногда и листочком A4, если работают двое-трое человек, а не пять-шесть) быстро, удобно и эффективно, но немасштабируемо на большее число людей и большее число деталей требований и архитектуры. Появляется огромный разрыв между тем, что решено на каком-нибудь "правлении", и последующей работой в крупной организации. Отчуждение от авторов флипчартовых описаний, участвовавших в начальных дискуссиях становится очень проблематичным.
4. Для фиксации требований и архитектурных описаний ISO 42010 рекомендует использовать архитектурные языки и подходы (framework) к архитектурному описанию (тут нужно учесть, что стандарт поминает architectural framework, но вот Open Group свой TOGAF называет не framework, а method. А поскольку мы уже перевели viewpoint как метод описания, относящийся к конкретной группе описаний -- view, то за framework оставляем слово "подход", заодно давая приоритет терминологии ISO 42010 над терминологией частных подходов-frameworks).
На сегодня есть множество популярных архитектурных языков: SysML/UML, AADL, ArchiMate и т.д.. Эти языки обычно объект-ориентированные и позволяют выразить объекты (классы, экземпляры, процессы, их атрибуты, отношения между экземплярами классов и т.д.). Язык мы тут понимаем как пара из языка и нотации (а иногда и нескольких нотаций) ISO 24744.
На сегодня есть множество популярных архитектурных подходов к описанию (architectural, или architecture framework, сводящихся к описанию набора view и их взаимосвязи): Захмановский, RM-ODP, TOGAF, DoDAF, ARIS и т.д..
Архитектурных подходов к описанию (т.е. наборов view) много больше, нежели языков, которые могут обеспечить viewpoints для этих view. С другой стороны, многие языки описания имеют свои предпочтения по поводу подхода к описанию -- ибо они предполагают использование отдельных видов диаграмм, которые легко перепутать с группами описаний (veiw). И люди их путают! Общее правило тут таково:
-- в архитектурных подходах разные view тематические, и могут подразумевать множество моделей для их описания. Например, финансовая группа описаний может требовать моделей баланса и отчёта о прибылях и убытках, группа описаний организации -- конструктивной диаграммы DEMO и органиграммы и т.д.
-- в архитектурных языках разные view прежде всего "онтологические", и чаще всего представляют собой какой-то один вид диаграмм. Так, в UML есть Activity Diagramm и Class Diagram.
Но на каждой общее правило есть множество исключений: если UML еще представляет собой более-менее чистый "язык", то уже ArchiMate содержит в себе существенную долю подхода к архитектурному описанию, а подход ARIS в существенной мере поддержан его же языком.
Это порождает много трудностей по использованию разных языков описания для выражения разных подходов -- по-хорошему, для любых подходов можно было бы использовать любые языки, но это не совсем так. См., например, серию обсуждений использования языка ArchiMate для подхода TOGAF: http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-an-architecture-method.html, http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-togaf.html, http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-togaf-2.html.
Более того, разные архитектурные языки могут мэппиться друг ко другу (концепты одного языка могут соотноситься с концептами другого языка, так что обеспечивается "перевод"), и из-за этого возникает дикая путаница между мэппингами языков и использованием языков для изображения разных групп описаний (см., например, https://doc.telin.nl/dsweb/Get/Document-38740/, где сравнивается ArchiMate и UML, RM-ODP, EDOC Profile for UML, BPMN, ARIS -- сам список того, с чем сравнивается ArchiMate поражает своей разнородностью).
5. Главная критика архитектурных языков: они невыразительны. На них нельзя многого выразить из того, что нужно для описания систем. Характерен анализ, данный при разработке онтологически-ориентированного архитектурного языка OPML ( http://www.cesames.net/fichier.php?id=370, http://www.cesames.net/fichier.php?id=371). Еще одно подтверждение невыразительности -- отсутствие имитационного моделирования (см. http://ailev.livejournal.com/819251.html).
Невыразительность, конечно, компенсируется: архитектурные языки просты, их легко выучить. Но это как Basic в языках программирования: недаром говорилось, что начавшего программировать на BASIC потом невозможно уже научить программировать хорошо. Выразить мир девятью корнями матерного диалекта можно, но лучше бы этого не делать в промышленных масштабах.
Проблема в том, что для большинства архитектурных языков за основу берется UML, и (невзирая на все отличия) поэтому вся критика UML относится и к архитектурным языкам. UML -- это такой архитектурый BASIC, коверкающий архитектурное мышление.
ПРЕДЛОЖЕНИЕ по решению ситуации с архитектурными языками: использовать для архитектурного языка какую-то upper ontology (например, ISO 15926-2). Несмотря на полное понимание, что для разных задач нужны разные онтологии ("нет универсального способа представления действительности"), каждая из них разрабатывалась с целью максимальной выразительности и расширяемости.
А для любых отдельных методов описания можно использовать микротеорию, разрабатываемую на основе этой базовой онтологии. Архитектурный язык становится тем самым ситуативным: модульно расширяемым по ситуации без потери выразительности. Каждая ситуация/система требует своего набора микротеорий, требуемых для ее описания.
6. Главная критика архитектурых подходов очень похожа на критику инженерии методов: они неситуативны. Любой архитектурный подход плохо работает в ситуации, хотя бы немного отличающейся от ситуации, для которой он разработан. Например, описание организационной (социотехнической) системы существенно отличается от описания "железной" (киберфизической) системы -- это означает, что подходы описания организационной архитектуры (enterprise architectural framework) должны бы существенно отличаться от подходов описания "просто систем", а ввиду невероятного различия между собой этих "просто систем" и использования в этих подходах архитектурных языков разной степени выразительности, нельзя быстро подобрать хоть как-то подходящий подход к архитектурному описанию.
Так, DoDAF является обязательным подходом для описания систем в военных закупках США. Но единогласное мнение: он заставляет подробно описывать неважное, а важное приходится описывать вне этого подхода!
Многочисленные попытки ввести "легковесные" подходы (типа LAF от Harold Lawson) пока ни к чему не привели, ибо критика относится к самому стилю использования одного и того же набора групп описаний для описания самых разных систем. Это неситуационно: "один размер не удовлетворит всех", даже если этот размер мал.
ПРЕДЛОЖЕНИЕ: аналогом ситуационного архитектурного подхода был бы заведомо избыточный каталог групп описаний, из которого можно было бы набирать небольшое число нужных в данной ситуации групп описаний -- плюс недостающие группы описаний можно было бы порождать каким-то регулярным способом.
7. По итогам двух предложений мы приходим к следующей конструкции:
а) в качестве архитектурного языка выбирается какая-то картина мира (upper ontology), в которую потом гарантированно впишутся многочисленные группы описаний
б) каждая группа описаний поддерживается своей микротеорией и соответствующей ей нотацией (DSL, viewpoint), а объекты разных микротеорий отождествляются друг с другом через correspondence view.
в) все эти DSL можно хранить в каталогах, и использовать по мере потребности -- понимая, что они будут совместимы между собой и всеми остальными описаниями (т.е. решена проблема интеграции данных разных описаний, даже если эти DSL поддерживаются разным софтом).
8. Я пытаюсь тут рассказать не столько о том, что подход (7) позволит формально определять все мэппинги из путаницы (4), оставляя людям возможность работать с лучшим инструментарием (т.е., это способ продолжить работать со множеством диалектов архитектурных Бейсиков). Нет, я не имею ввиду что-то типа "ISO 15926 outside для архитектурного моделирования", чтобы как-то определять correspondence rules для программных средств архитектурного моделирования разных производителей, поддерживающих разные подходы и языки.
Скорее, я имею ввиду развитие чего-то типа "ISO 15926 offsite" (http://dot15926.livejournal.com/22909.html), создание нового расширяемого архитектурного языка для requirements and architecture acquisition -- в форме библиотеки справочных данных (каталога DSL, т.е. микротеорий+нотаций, aka каталога групп описаний, aka каталога ситуационного архитектурного подхода). В этот ситуационный архитектурный подход можно было бы интегрировать удачные находки нынешних архитектурных бейсиков, но оставить возможность развития (т.е. систематического пополнения этой библиотеки).
9. А пока из всего этого разнообразия для целей описания организационной архитектуры мне больше всего нравится ArchiMate (http://www.opengroup.org/archimate/doc/ts_archimate/, свободный моделер -- http://archi.cetis.ac.uk/), за которым я слежу уже некоторое время. Если нужно что-то делать срочно, то я бы брал его за основу. Даже любители ARIS могут его использовать (http://www.ids-scheer.ru/ru/ARIS/ARIS_Software/ARIS_ArchiMate_Modeler/35028.html), равно как и любители другого платного софта (http://www.bizzdesign.com/index.php/tools/architect и т.д.).
Недостатки, как водится, являются отражением достоинств: небольшое количество предметно-ориентированных базовых языковых концептов (микротеории организации), приписанных к четко указанным возможным view (матрице слоёв*аспектов) -- Business Layer (Business actor, Business role, Business collaboration, Business interface ...), Application Layer (Application component, Application collaboration, Application interface, Data object ...), Technology Layer (Node, Device, Network, Communication path ...), Relationships (Association, Access, Used by, Realization, Assignment ...).
В этом языке-подходе переплелись средства как предмет-ориентированные (описание организации и ее технологической инфраструктуры), так и общие (т.е. непредметно-ориентированные, типа объектов representation, отношений aggregation, composition и т.д.). Понятно, что для конкретных целей ситуации моделирования может не хватить ни тех, ни других.
Детализация описания, выход в более специализированные модели, и тем самым обеспечение исполняемости описаний (например, BPMN описания процессов, которые можно было бы скормить какому-нибудь workflow-движку; описание данных, которые можно было бы скормить какой-нибудь СУБД) представляется более чем ограниченными.
Плохо также и то, что за основу явно берется UML -- везде, где только можно. Это существенно ограничивает онтологическую выразительность.
10. Главная критика текущих подходов к архитектурному описанию: их группы описаний пытаются быть недеятельностными, т.е. независящими от используемых методов работы. Это означает, что мы не можем описать финансы так, чтобы было удобно для маржиналистской работы с ними (throughput accounting) и традиционной (cost world, в которой постоянные и переменные издержки перемешаны). Мы не можем описать организационный мир в терминах транзакций, путаемся между функциональным (т.е. типа IDEF0, без развертки во времени) и процессным (т.е. типа IDEF3, с разверткой по времени) описаниями "процессов", не понимаем, как в это упихнуть "проекты" в смысле проектного управления и т.д.
Тезис: разные методы работы с системой (в том числе, организационной/социотехнической системой, но и с киберфизической тоже -- с любой системой) требуют каких-то микротеорий, и разные группы описаний архитектуры должны поддерживать именно нужные для выборанных методов работы описания.
Уйти от этого нельзя, даже если пытаться ограничиться "общим архитектурным языком". Либо ты различаешь физический объект и функциональный объект, используя методы системного подхода, и это отражается в архитектурном языке; или различаешь актора и акторские роли, и это отражается в архитектурном языке, либо этого ничего нет, и получаемые в рамках какой-то пары архитектурного подхода и языка группы описаний оказывается невозможно использовать.
Тем самым задача создания архитектурного подхода к описанию (набора групп описаний и каталога методов описаний) вынуждена быть совмещенной с задачей создания каталога методов, которые используются при разработке. Ежели архитектурный метод (например, ТРИЗ), выделяет "противоречие", как важный элемент архитектурной работы, то и архитектурное описание должно позволять его отображать. Ежели выделяет разницу между механизмом, поведением, структурой, конструкцией и т.д. -- то эта разница должна получить отражение в соответствующих группах описаний.
Об этом я, кажется, уже много раз писал -- но уж лучше написать еще раз прямо, чем потом задаваться вопросом, почему мы не можем использовать готовый софт поддержки давно известных архитектурных языков (т.е. конкретные диаграммные технологии) и готовые архитектурные подходы к описаниям (т.е. наборы предписанных групп описаний).
12. Поэтому задача создания архитектурного подхода к описанию системы вполне укладывается в задачу создания каталога методов: это как раз "язык" и "нотация" из ISO 24744. Трудность тут только в том, что формализм ISO 24744 не позволяет легко выражать связку между всеми этими языками и нотациями. Но на данном уровне рассуждений это и неважно.
Так что, ежели развивать каталог методов организационной работы praxos, то автоматически нужно ставить и задачу создания онтологического (т.е. всеядного, основанного на микротеориях) архитектурного языка для описания организаций как системы связанных разными отношениями людей, оборудования, данных, так и разных взаимоувязанных DSL (язык плюс нотация) для поддержки методов работы с организацией. То есть без понимания, как ты будешь делать, не будет понимания, как ты будешь архитектурить (это про определение обеспечивающей системы, в отличие от понимания, что ты будешь делать, и что архитектурить -- это будет выясняться по ходу работы, это про определение целевой системы).
Поэтому идея Harold Lawson ("LAF следует группам практик из ISO 15288") в целом верная: начинать нужно с каталога методов работы с системой, а не с определений "что обычно входит к корпоративную архитектуру" или "какие группы описаний обычно нужны стейкхолдерам сложного инженерного объекта", "какие группы описаний нужны для работы с PLM" и т.д.
2. Лучшим на сегодня мне известным способом быстро обеспечить архитектурное описание, равно как и зафиксировать требования, является малевание от руки простых диаграммок фломастером на флипчарте (архитектурное описание, с приписанными там да сям отдельными словами, обозначающими требования), сопровождаемые словами из разных статей, учебников и прошлых жизненных ситуаций (ситуационный метод, вытаскиваемый из библиотеки компонент метода -- прямо из головы).
Хихикну в сторону, что аналитические диаграммы ISO 15926 во всём мире сейчас тоже рисуют карандашом на бумажке, в крайнем случае -- в PowerPoint, Word или Visio. Сапожники, как водится, без сапог: кто предлагает универсальные языки описания всего, читаемые машиной, сам остаётся без такого языка.
Итого: технологии по факту нет -- дисциплина не описана, и передаётся исключительно изустно, язык описания требований и архитектуры неформален, инструменты времён изобретения доски с мелом. Самый современный инструмент -- это телефон, на который фотографируют флипчарт.
3. С флипчартом (а иногда и листочком A4, если работают двое-трое человек, а не пять-шесть) быстро, удобно и эффективно, но немасштабируемо на большее число людей и большее число деталей требований и архитектуры. Появляется огромный разрыв между тем, что решено на каком-нибудь "правлении", и последующей работой в крупной организации. Отчуждение от авторов флипчартовых описаний, участвовавших в начальных дискуссиях становится очень проблематичным.
4. Для фиксации требований и архитектурных описаний ISO 42010 рекомендует использовать архитектурные языки и подходы (framework) к архитектурному описанию (тут нужно учесть, что стандарт поминает architectural framework, но вот Open Group свой TOGAF называет не framework, а method. А поскольку мы уже перевели viewpoint как метод описания, относящийся к конкретной группе описаний -- view, то за framework оставляем слово "подход", заодно давая приоритет терминологии ISO 42010 над терминологией частных подходов-frameworks).
На сегодня есть множество популярных архитектурных языков: SysML/UML, AADL, ArchiMate и т.д.. Эти языки обычно объект-ориентированные и позволяют выразить объекты (классы, экземпляры, процессы, их атрибуты, отношения между экземплярами классов и т.д.). Язык мы тут понимаем как пара из языка и нотации (а иногда и нескольких нотаций) ISO 24744.
На сегодня есть множество популярных архитектурных подходов к описанию (architectural, или architecture framework, сводящихся к описанию набора view и их взаимосвязи): Захмановский, RM-ODP, TOGAF, DoDAF, ARIS и т.д..
Архитектурных подходов к описанию (т.е. наборов view) много больше, нежели языков, которые могут обеспечить viewpoints для этих view. С другой стороны, многие языки описания имеют свои предпочтения по поводу подхода к описанию -- ибо они предполагают использование отдельных видов диаграмм, которые легко перепутать с группами описаний (veiw). И люди их путают! Общее правило тут таково:
-- в архитектурных подходах разные view тематические, и могут подразумевать множество моделей для их описания. Например, финансовая группа описаний может требовать моделей баланса и отчёта о прибылях и убытках, группа описаний организации -- конструктивной диаграммы DEMO и органиграммы и т.д.
-- в архитектурных языках разные view прежде всего "онтологические", и чаще всего представляют собой какой-то один вид диаграмм. Так, в UML есть Activity Diagramm и Class Diagram.
Но на каждой общее правило есть множество исключений: если UML еще представляет собой более-менее чистый "язык", то уже ArchiMate содержит в себе существенную долю подхода к архитектурному описанию, а подход ARIS в существенной мере поддержан его же языком.
Это порождает много трудностей по использованию разных языков описания для выражения разных подходов -- по-хорошему, для любых подходов можно было бы использовать любые языки, но это не совсем так. См., например, серию обсуждений использования языка ArchiMate для подхода TOGAF: http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-an-architecture-method.html, http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-togaf.html, http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-togaf-2.html.
Более того, разные архитектурные языки могут мэппиться друг ко другу (концепты одного языка могут соотноситься с концептами другого языка, так что обеспечивается "перевод"), и из-за этого возникает дикая путаница между мэппингами языков и использованием языков для изображения разных групп описаний (см., например, https://doc.telin.nl/dsweb/Get/Document-38740/, где сравнивается ArchiMate и UML, RM-ODP, EDOC Profile for UML, BPMN, ARIS -- сам список того, с чем сравнивается ArchiMate поражает своей разнородностью).
5. Главная критика архитектурных языков: они невыразительны. На них нельзя многого выразить из того, что нужно для описания систем. Характерен анализ, данный при разработке онтологически-ориентированного архитектурного языка OPML ( http://www.cesames.net/fichier.php?id=370, http://www.cesames.net/fichier.php?id=371). Еще одно подтверждение невыразительности -- отсутствие имитационного моделирования (см. http://ailev.livejournal.com/819251.html).
Невыразительность, конечно, компенсируется: архитектурные языки просты, их легко выучить. Но это как Basic в языках программирования: недаром говорилось, что начавшего программировать на BASIC потом невозможно уже научить программировать хорошо. Выразить мир девятью корнями матерного диалекта можно, но лучше бы этого не делать в промышленных масштабах.
Проблема в том, что для большинства архитектурных языков за основу берется UML, и (невзирая на все отличия) поэтому вся критика UML относится и к архитектурным языкам. UML -- это такой архитектурый BASIC, коверкающий архитектурное мышление.
ПРЕДЛОЖЕНИЕ по решению ситуации с архитектурными языками: использовать для архитектурного языка какую-то upper ontology (например, ISO 15926-2). Несмотря на полное понимание, что для разных задач нужны разные онтологии ("нет универсального способа представления действительности"), каждая из них разрабатывалась с целью максимальной выразительности и расширяемости.
А для любых отдельных методов описания можно использовать микротеорию, разрабатываемую на основе этой базовой онтологии. Архитектурный язык становится тем самым ситуативным: модульно расширяемым по ситуации без потери выразительности. Каждая ситуация/система требует своего набора микротеорий, требуемых для ее описания.
6. Главная критика архитектурых подходов очень похожа на критику инженерии методов: они неситуативны. Любой архитектурный подход плохо работает в ситуации, хотя бы немного отличающейся от ситуации, для которой он разработан. Например, описание организационной (социотехнической) системы существенно отличается от описания "железной" (киберфизической) системы -- это означает, что подходы описания организационной архитектуры (enterprise architectural framework) должны бы существенно отличаться от подходов описания "просто систем", а ввиду невероятного различия между собой этих "просто систем" и использования в этих подходах архитектурных языков разной степени выразительности, нельзя быстро подобрать хоть как-то подходящий подход к архитектурному описанию.
Так, DoDAF является обязательным подходом для описания систем в военных закупках США. Но единогласное мнение: он заставляет подробно описывать неважное, а важное приходится описывать вне этого подхода!
Многочисленные попытки ввести "легковесные" подходы (типа LAF от Harold Lawson) пока ни к чему не привели, ибо критика относится к самому стилю использования одного и того же набора групп описаний для описания самых разных систем. Это неситуационно: "один размер не удовлетворит всех", даже если этот размер мал.
ПРЕДЛОЖЕНИЕ: аналогом ситуационного архитектурного подхода был бы заведомо избыточный каталог групп описаний, из которого можно было бы набирать небольшое число нужных в данной ситуации групп описаний -- плюс недостающие группы описаний можно было бы порождать каким-то регулярным способом.
7. По итогам двух предложений мы приходим к следующей конструкции:
а) в качестве архитектурного языка выбирается какая-то картина мира (upper ontology), в которую потом гарантированно впишутся многочисленные группы описаний
б) каждая группа описаний поддерживается своей микротеорией и соответствующей ей нотацией (DSL, viewpoint), а объекты разных микротеорий отождествляются друг с другом через correspondence view.
в) все эти DSL можно хранить в каталогах, и использовать по мере потребности -- понимая, что они будут совместимы между собой и всеми остальными описаниями (т.е. решена проблема интеграции данных разных описаний, даже если эти DSL поддерживаются разным софтом).
8. Я пытаюсь тут рассказать не столько о том, что подход (7) позволит формально определять все мэппинги из путаницы (4), оставляя людям возможность работать с лучшим инструментарием (т.е., это способ продолжить работать со множеством диалектов архитектурных Бейсиков). Нет, я не имею ввиду что-то типа "ISO 15926 outside для архитектурного моделирования", чтобы как-то определять correspondence rules для программных средств архитектурного моделирования разных производителей, поддерживающих разные подходы и языки.
Скорее, я имею ввиду развитие чего-то типа "ISO 15926 offsite" (http://dot15926.livejournal.com/22909.html), создание нового расширяемого архитектурного языка для requirements and architecture acquisition -- в форме библиотеки справочных данных (каталога DSL, т.е. микротеорий+нотаций, aka каталога групп описаний, aka каталога ситуационного архитектурного подхода). В этот ситуационный архитектурный подход можно было бы интегрировать удачные находки нынешних архитектурных бейсиков, но оставить возможность развития (т.е. систематического пополнения этой библиотеки).
9. А пока из всего этого разнообразия для целей описания организационной архитектуры мне больше всего нравится ArchiMate (http://www.opengroup.org/archimate/doc/ts_archimate/, свободный моделер -- http://archi.cetis.ac.uk/), за которым я слежу уже некоторое время. Если нужно что-то делать срочно, то я бы брал его за основу. Даже любители ARIS могут его использовать (http://www.ids-scheer.ru/ru/ARIS/ARIS_Software/ARIS_ArchiMate_Modeler/35028.html), равно как и любители другого платного софта (http://www.bizzdesign.com/index.php/tools/architect и т.д.).
Недостатки, как водится, являются отражением достоинств: небольшое количество предметно-ориентированных базовых языковых концептов (микротеории организации), приписанных к четко указанным возможным view (матрице слоёв*аспектов) -- Business Layer (Business actor, Business role, Business collaboration, Business interface ...), Application Layer (Application component, Application collaboration, Application interface, Data object ...), Technology Layer (Node, Device, Network, Communication path ...), Relationships (Association, Access, Used by, Realization, Assignment ...).
В этом языке-подходе переплелись средства как предмет-ориентированные (описание организации и ее технологической инфраструктуры), так и общие (т.е. непредметно-ориентированные, типа объектов representation, отношений aggregation, composition и т.д.). Понятно, что для конкретных целей ситуации моделирования может не хватить ни тех, ни других.
Детализация описания, выход в более специализированные модели, и тем самым обеспечение исполняемости описаний (например, BPMN описания процессов, которые можно было бы скормить какому-нибудь workflow-движку; описание данных, которые можно было бы скормить какой-нибудь СУБД) представляется более чем ограниченными.
Плохо также и то, что за основу явно берется UML -- везде, где только можно. Это существенно ограничивает онтологическую выразительность.
10. Главная критика текущих подходов к архитектурному описанию: их группы описаний пытаются быть недеятельностными, т.е. независящими от используемых методов работы. Это означает, что мы не можем описать финансы так, чтобы было удобно для маржиналистской работы с ними (throughput accounting) и традиционной (cost world, в которой постоянные и переменные издержки перемешаны). Мы не можем описать организационный мир в терминах транзакций, путаемся между функциональным (т.е. типа IDEF0, без развертки во времени) и процессным (т.е. типа IDEF3, с разверткой по времени) описаниями "процессов", не понимаем, как в это упихнуть "проекты" в смысле проектного управления и т.д.
Тезис: разные методы работы с системой (в том числе, организационной/социотехнической системой, но и с киберфизической тоже -- с любой системой) требуют каких-то микротеорий, и разные группы описаний архитектуры должны поддерживать именно нужные для выборанных методов работы описания.
Уйти от этого нельзя, даже если пытаться ограничиться "общим архитектурным языком". Либо ты различаешь физический объект и функциональный объект, используя методы системного подхода, и это отражается в архитектурном языке; или различаешь актора и акторские роли, и это отражается в архитектурном языке, либо этого ничего нет, и получаемые в рамках какой-то пары архитектурного подхода и языка группы описаний оказывается невозможно использовать.
Тем самым задача создания архитектурного подхода к описанию (набора групп описаний и каталога методов описаний) вынуждена быть совмещенной с задачей создания каталога методов, которые используются при разработке. Ежели архитектурный метод (например, ТРИЗ), выделяет "противоречие", как важный элемент архитектурной работы, то и архитектурное описание должно позволять его отображать. Ежели выделяет разницу между механизмом, поведением, структурой, конструкцией и т.д. -- то эта разница должна получить отражение в соответствующих группах описаний.
Об этом я, кажется, уже много раз писал -- но уж лучше написать еще раз прямо, чем потом задаваться вопросом, почему мы не можем использовать готовый софт поддержки давно известных архитектурных языков (т.е. конкретные диаграммные технологии) и готовые архитектурные подходы к описаниям (т.е. наборы предписанных групп описаний).
12. Поэтому задача создания архитектурного подхода к описанию системы вполне укладывается в задачу создания каталога методов: это как раз "язык" и "нотация" из ISO 24744. Трудность тут только в том, что формализм ISO 24744 не позволяет легко выражать связку между всеми этими языками и нотациями. Но на данном уровне рассуждений это и неважно.
Так что, ежели развивать каталог методов организационной работы praxos, то автоматически нужно ставить и задачу создания онтологического (т.е. всеядного, основанного на микротеориях) архитектурного языка для описания организаций как системы связанных разными отношениями людей, оборудования, данных, так и разных взаимоувязанных DSL (язык плюс нотация) для поддержки методов работы с организацией. То есть без понимания, как ты будешь делать, не будет понимания, как ты будешь архитектурить (это про определение обеспечивающей системы, в отличие от понимания, что ты будешь делать, и что архитектурить -- это будет выясняться по ходу работы, это про определение целевой системы).
Поэтому идея Harold Lawson ("LAF следует группам практик из ISO 15288") в целом верная: начинать нужно с каталога методов работы с системой, а не с определений "что обычно входит к корпоративную архитектуру" или "какие группы описаний обычно нужны стейкхолдерам сложного инженерного объекта", "какие группы описаний нужны для работы с PLM" и т.д.