Международный стандарт описания архитектуры: задаёт, из чего состоит архитектурное описание — заинтересованные стороны, интересы, точки зрения, представления и правила соответствия между ними. Реестр заполнен по редакции 2011 года (идентичный ГОСТ Р 57100-2016).
Врач хочет знать, будет ли доступна история лечения, эксплуатация — как восстановиться после сбоя, финансист — во что обойдётся интеграция. Им приносят один документ на сто страниц, и ответа в нём не находит никто.
Обычный архитектурный документ собирают из привычного набора: контекст, компоненты, развёртывание, интеграции. По меркам автора он полный. Читатель с конкретным вопросом в нём тонет: чтобы понять, восстановится ли система после сбоя, надо самому сложить три схемы и пять таблиц, а потом всё равно позвонить архитектору. Причина не в качестве схем. Никто не записал, кто будет читать документ и какие вопросы у этих людей есть, — и поэтому состав описания определили не вопросы, а привычка.
ISO 42010 начинает с другого конца. Сначала заинтересованные стороны — все, у кого есть интерес к системе, а не только заказчик. Потом их интересы: любая тема, из-за которой к системе есть вопросы. Под интересы выбираются точки зрения — правила, по которым строится и читается представление: какие модели, в какой нотации, по каким условностям. Точка зрения, применённая к вашей системе, даёт представление. Сверху две вещи, которые обычно пропускают: правила связи между представлениями, чтобы один интерфейс выглядел одинаково в функциональной и эксплуатационной схемах, и обоснование — почему выбраны эти точки зрения и эти решения. Стандарт ничего не говорит о том, из чего состоит предприятие: он про то, как устроен документ.
Поэтому в реестре школа стоит в разделе «Около корпоративной архитектуры»: это правила для описаний, а не модель предприятия, и они одинаково накладываются на TOGAF, на любую другую рамку или на ваш собственный набор схем. В раздатке — 31 карточка страницы реестра по тексту ГОСТ Р 57100-2016: десять терминов, требования разделов 5–7 и десять разделов шаблона точки зрения из приложения B. Плюс три понятия с бытовыми объяснениями, пример больницы, которая планирует информационную систему, и план на пять рабочих дней.
Описание архитектуры сделано хорошо, когда у каждого представления есть читатель с вопросом, а у каждого вопроса — представление с ответом.
Исследуйте основные части: у каждой свой вопрос, смысл и место в примере.
ISO 42010
Выберите элемент схемы — откроются объяснение и пример.
Заинтересованная сторона у 42010 определена предельно скупо: это тот, у кого есть интерес в системе, — ни роли, ни полномочий, ни места в оргструктуре от неё не требуется. Нужна она потому, что на ней держится вся цепочка стандарта: сторона — интерес — точка зрения — представление.
Выделяем врачей, администраторов, службу эксплуатации и ответственных за данные.
Выборочный авторский навигатор по подходу. Схема упрощена для объяснения; полный состав записей и источники — в каталоге ниже.
Авторский учебный пример. Организация и решения придуманы для объяснения подхода; это не обязательный порядок работ из стандарта.
Записываем конкретные вопросы к будущей системе и стороны, которым нужны ответы.
Состав описания основан на потребности, а не на привычном наборе схем.
Определяем правила представлений и строим модели для больницы.
Каждое представление отвечает на определённый круг вопросов.
Сопоставляем модели и сохраняем обоснования принятых решений.
Противоречия между описаниями становятся предметом проверки.
Разбираемся в методе на одном примере: сеть магазинов запускает самовывоз. Пройдём цикл ADM, свяжем бизнес, данные, приложения и технологии, выберем артефакты и составим план перехода.
Разбираем архитектуру предприятия на примере логистической сети. Выбирайте представления в сетке UAF, прослеживайте связи операций, сервисов, людей и ресурсов и находите нужные элементы в каталоге.
Единый язык моделирования корпоративной архитектуры от The Open Group. В редакции 4 язык разложен не по слоям, а по доменам: четыре домена ядра — Common, Business, Application и Technology — плюс Motivation, Strategy и Implementation and Migration. Для каждого домена задан свой набор элементов, а все разрешённые отношения сведены в нормативное приложение B. Отдельного домена для информации и данных язык не заводит намеренно: информация моделируется сквозь домены элементами пассивной структуры. Реестр держит редакцию 4 и рядом 70 строк редакции 3.2 — из сводной матрицы школ старая редакция исключена.
Точка зрения задаёт правила и интересы, представление применяет их к конкретному объекту. Шаблон и заполненное описание выполняют разные роли.
Перед проработкой согласуйте вопрос: Кому нужно это описание? Ответ должен быть понятен участникам рассматриваемой работы.
Пройдите весь пример от исходной ситуации до результата: Противоречия между описаниями становятся предметом проверки.
Общие оси — нейтральные названия частей предприятия: деятельность, данные, приложения, инфраструктура и другие. Здесь показано, какие элементы подхода сопоставлены с этими осями и насколько совпадает их охват.
Собственная структура этого подхода построена по другим признакам — например, слоям, фазам или уровням абстракции. Она не сопоставлена с предметными осями реестра.
| Ось реестра | В ISO 42010 | Сопоставление | Пояснение |
|---|---|---|---|
| Делит по другому признаку | No mandatory domain/viewpoint taxonomyбез закреплённых доменов | Вне общих осей | Стандарт намеренно не задаёт обязательных доменов: он описывает, КАК строить архитектурное описание, а не из чего состоит предприятие. |
| Делит по другому признаку | Stakeholder · Concern · Architecture Viewpoint · Architecture Viewизмерение | Вне общих осей | Конструкции самого стандарта 42010: заинтересованная сторона, интерес, точка зрения и представление. Это аппарат описания архитектуры, а не предметные домены. |
Дополнительные измерения этого подхода: без закреплённых доменов.
Полное описание предприятия — работа на месяцы. Первый полезный результат получается за пять рабочих дней, если не пытаться описать всё сразу.
Одним абзацем запишите, какую систему описываете, где её границы и что её окружает. Затем выпишите заинтересованные стороны — всех, у кого есть интерес: не только спонсора, но и врачей, эксплуатацию, безопасность, смежные команды. Это обязанность пункта 5.3 и первое, что читатель ищет в документе.
Для каждой стороны запишите вопросы, которые она задаст системе: будет ли доступна история лечения, как восстановиться после сбоя, во что обойдётся интеграция. Один интерес может быть общим для нескольких сторон. К концу дня у вас таблица «сторона × интерес» — состав описания теперь определяют вопросы, а не привычный набор схем.
Сгруппируйте интересы и под каждую группу подберите точку зрения: какие виды моделей, в какой нотации, по каким условностям. Возьмите готовые из фреймворка, которым пользуетесь, или опишите свои по шаблону приложения B: имя, обзор, интересы, типичные стороны, виды моделей, источники. Проверьте, что у каждого интереса есть точка зрения, которая его закрывает.
Примените каждую точку зрения к своей системе: одно представление на точку зрения, внутри — модели по её правилам. Отдельно запишите известные проблемы представления — стандарт требует этого явно. Для больницы это, например, реальное распределение компонентов и связи, значимые для восстановления после сбоя.
Сформулируйте правила связи между представлениями — один интерфейс, один компонент должны быть одинаковыми во всех схемах — и проверьте их. Запишите обоснование: почему такие точки зрения, почему такие решения, какие альтернативы отвергнуты. Добавьте обвязку пункта 5.2: о какой системе документ, автор, версия, дата. Теперь описание проходит раздел 5 целиком.
Заинтересованная сторона у стандарта — любой, у кого есть интерес к системе: эксплуатация, безопасность, пользователи, регулятор, соседняя команда, чью систему вы интегрируете. Пропущенная сторона — это пропущенный интерес, а значит, представление, которого никто не сделал. Вопрос всплывёт на приёмке, когда менять состав описания уже дорого.
Обоснование — единственное, что стандарт требует объяснить словами: почему выбраны эти точки зрения и почему принято каждое ключевое решение, с рассмотренными альтернативами. Без него каждый новый участник открывает спор заново, а описание через год отвечает на вопрос «что», но не на вопрос «почему так». Достаточно абзаца на решение, записанного в момент выбора.
TOGAF — метод и содержательная рамка корпоративной архитектуры: в каком порядке работать и что должно получиться. ISO 42010 — требования к любому описанию архитектуры и к любой рамке: раздел 6 говорит, при каких условиях набор точек зрения можно назвать структурой архитектуры и что значит «документ сделан по фреймворку». TOGAF сам пользуется словарём 42010 — точками зрения и представлениями. Их применяют вместе: TOGAF отвечает, что делать, 42010 — как оформить, чтобы читалось.
Нет. Нотацию задаёт точка зрения через виды моделей: диаграмма классов, сеть Петри, организационная структура, бухгалтерский баланс — стандарт сам приводит такие примеры. Представление может быть таблицей или текстом, если так договорено. Язык описания архитектуры — форма выражения, к которой стандарт предъявляет условия, а не единственный допустимый способ.
Да. Объём описания определяют количество сторон и интересов, а не размер стандарта. Для одной системы это обычно несколько сторон, несколько интересов и пара точек зрения и описание на несколько страниц. Стандарт требует состава — стороны, интересы, точки зрения, представления, обоснование, — а не толщины документа. Маленькой команде он полезен тем, что через год кто-то другой поймёт, почему сделано так.
19 страниц: что это и чем не является, устройство подхода, 31 карточка словаря, 3 понятия с аналогиями, учебный пример и план первой недели.
Пришлём ссылку сразу после отправки формы
Дословные выписки из стандарта с переводом.
Понятия этого подхода с объяснениями, примерами и типичными ошибками.
Заинтересованная сторона — тот, у кого есть интерес к системе или к решению: человек, команда, организация.
Представление — это то, что читатель держит в руках: часть описания архитектуры, показывающая её под определённым углом.
Точка зрения — это соглашения о том, как делать и читать представление: что показывать, какими значками и для чьего интереса.
Подходы для одной области — безопасность, производство, ИТ-функция — и стандарты о том, как вообще описывать архитектуру: требования, правила, принципы.
Русское издание ГОСТ Р 57100-2016 подготовлено ООО «ИАВЦ» на основе собственного аутентичного перевода, внесено ТК 22 «Информационные технологии», утверждено и введено в действие приказом Росстандарта от 22 сентября 2016 года № 1190-ст, введено впервые; дата введения — 1 сентября 2017 года, переиздание — январь 2019 года. Стандарт идентичен ISO/IEC/IEEE 42010:2011.
Введение самого ISO/IEC/IEEE 42010 говорит, что этот первый выпуск отменяет и заменяет технически пересмотренный ИСО/МЭК 42010:2007, и что подготовлен он Подкомитетом 7 «Системная и программная инженерия» совместного технического комитета ИСО/МЭК СТК 1 «Информационные технологии» в сотрудничестве с комитетом по стандартам системной и программной инженерии Компьютерного общества ИИЭР. На ANSI/IEEE Std 1471-2000 стандарт ссылается по тексту — и как на источник определения программно-интенсивной системы, и при разборе согласованности представлений; в библиографии это позиция [1].
Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.
Это же в StormАрхитектура систем и интеграцийБаза знаний и викиРеестр процессов
