Архитекторы предприятий рассматривают предприятие как систему, каждый из модулей которой можно смоделировать с точки зрения ролей и процессов.
Внешняя организация [Логический или физический компонент] вне интересующего бизнеса или системы, который взаимодействует с этим бизнесом или системой путем запроса или предоставления услуг. Актер [Физический компонент] или физическое лицо, способное играть одну или несколько ролей в выполнении процессов. (Если нечеловеческие субъекты представлены в виде прикладных и / или технологических компонентов, то действующие лица должны быть людьми.) Организационное подразделение [Физический компонент] или отдельный узел в структуре управления, способный выполнять одну или несколько функций. У него должны быть цели и задачи с мерами и менеджер. Роль [Логический компонент], реализуемый или используемый отдельными участниками, определяемый с точки зрения предоставляемых услуг и / или выполняемых процессов и требуемых способностей. Функция [Логический компонент], целостный набор моделей поведения, требуемых от любого подразделения организации, выполняющего функцию, определенную с точки зрения предоставляемых услуг и / или выполняемых процессов и требуемых способностей. (Это логическая бизнес-возможность, которую не следует путать с управляемой организационной единицей или отдельным бизнес-сервисом.) Бизнес -процесс [Процесс], который выполняется участниками бизнеса с использованием информационных технологий или без них. Бизнес-сервис [Услуга], которую можно запросить у бизнеса или его компонента. (Не путать с бизнес-функцией .) Объект данных [Элемент данных], состоящий из элементов данных, которые представляют факты о дискретном бизнес-объекте или событии. Он может быть задан на концептуальном, логическом или физическом уровне. Это может быть сопоставлено с хранилищами данных и / или потоками данных, вводимыми в службы ИБ или выводимыми из них. IS (приложение) сервис [Услуга], которая может быть запрошена у бизнес-ориентированного компонента приложения человеком-субъектом или другим компонентом приложения. Прикладной компонент [Компонент] бизнес-ориентированного программного обеспечения (например, CRM, биллинг). Логически это определяется предоставляемыми ИТ-службами, а иногда также объектами данных, которые оно поддерживает, и / или физически как продукт, специфичный для поставщика / технологии, который можно нанять, купить или создать. Платформенный сервис [Услуга], которая может быть запрошена у технологического компонента прикладным компонентом или другим технологическим компонентом. Технологический компонент [Компонент] общего программного обеспечения инфраструктуры (например, ОС, СУБД). Логически он определяется предоставляемыми им сервисами платформы и / или физически как продукт, специфичный для поставщика / технологии, который можно нанять или купить.
Корпоративные архитекторы моделируют динамические системы деятельности организации, информационно-зависимые процессы. Моделируют логическиепроцессы и потоки данных (т.е. роли и процессы), создающие и использующие данные, которые бизнесу необходимо отслеживать или направлять.
Проектируемые системы представляют собой зоны упорядоченного поведения. Бизнес-система (мебельная фабрика, маркетплейс, завод по производству автомобилей) — это зона стабильного и упорядоченного поведения в постоянно развивающейся истории предприятия. Мы можем смоделировать ее обычное поведение.
*Формализация — представление какой-либо содержательной области (рассуждений, доказательств, процедур классификации, поиска информации, научных теорий) в виде формальной системы или исчисления
Пример: Оглавление книги — это формализация её содержательных частей, а сам текст книги можно рассмотривать как формализацию по средством языковых конструкций мыслей, идей, размышлений автора. Итогом формализации научной теории является, как правило, совокупность формул, графиков,схем, таблиц и так далее.
То, что люди говорят и делают спонтанно, интеллектуально или творчески, может быть упомянуто в моделях бизнес-систем, но только как контекст работы, который можно формализовать и смоделировать в терминах регулярного поведения, управляемого событиями.
Архитекторы предприятий не являются социологами, архитекторы бизнес-систем моделируют не людей; они моделируют их распределение по ролям.
Социальные системы состоят из действующих лиц, которые общаются и выполняют действия в соответствии с полученными сообщениями и сохраненными воспоминаниями.
Бизнес-системы — это социальные системы, в которых роли формализованы, сообщения формализованы в потоках данных, память формализована в хранилищах данных, а действия выполняются в ответ на отдельные события.
Архитекторы предприятий и решений не строят самолеты, не разрабатывают новые лекарства, не проектируют производственные линии, не роют ямы на дорогах и не снимают фильмы. Они стремятся оптимизировать и интегрировать бизнес-роли и процессы за счет лучшего использования бизнес-информации, создаваемой этими ролями и процессами. Они не внедряют инновации в области машиностроения, биохимии или творчества. Они действительно ищут новые возможности для оцифровки и интеграции ролей и процессов, а также использования собранной информации.
Потребность в такой корпоративной архитектуре не нова, и она никогда не исчезнет.
Корпоративные архитекторы моделируют не все, чем является бизнес или что он делает. Они фокусируются на том, где физический (ручной, механический, материальный) мир соединяется с миром логической информации. О ролях и процессах, которые создают или используют информацию в ходе предоставления бизнес-продуктов и услуг. И об улучшении бизнес-операций за счет интеграции информации, создаваемой и используемой на предприятии.
СЛОВАРНЫЙ ЗАПАС КОРПОРАТИВНОГО АРХИТЕКТОРА
Как бизнес-система формализует социальную систему? Взаимоотношения между субъектами определяются через установление того, какие действия может вызвать сообщение, согласование смысла передаваемых сообщений и сохранённых воспоминаний.
Для формализации и интеграции поведения стороны должны согласовать значения символов, которые они создают и используют в сообщениях и памяти. Это в равной степени относится к людям, работающим в операционных системах, и архитекторам, моделирующим эти системы.
Естественный язык свободен и двусмыслен. Слова, которые мы используем для описания вещей, представляют собой вербальные кодировки нечетких ментальных моделей.
Русский язык насчитывает более 200 000 слов, разные слова имеют одинаковое значение, а одно слово имеет несколько значений. Например: является ли “сервис” типом процесса, экземпляром переходного процесса, постоянной функцией или ролью, отвечающей за различные типы процессов и экземпляры? Чем это отличается от ”функции“ или «роли”?
Это не беспокоит нас в повседневных обсуждениях. Но профессиональная спецификация бизнес-систем — это совсем другое дело. Если графические символы в языке системного моделирования представляют собой просто слова, поскольку люди используют их естественным образом, то язык моделирования будет таким же большим, расплывчатым и двусмысленным, как и естественный язык.
Естественно, мы не используем слова логичным и упорядоченным образом. Тем не менее, это именно то, к чему мы стремимся при описании формализованных систем, которые должны быть построены, развернуты и использоваться другими. Профессиональным системным архитекторам необходим контролируемый словарный запас. Язык описания бизнес-систем должен строго и недвусмысленно различать типы системных элементов (таких как сервис, функция и интерфейс), чтобы архитекторы бизнес-систем могли использовать их согласованным образом и легко понимать друг друга.
Профессиональный язык моделирования систем должен быть более дисциплинированным, чем естественный язык. Это должно помочь архитекторам описывать участников системы и действия, используя небольшое количество символов / слов – значение которых не двусмысленно, чтобы избежать расплывчатости естественного языка. Профессионалам, возможно, придется переводить свои модели на любой естественный язык, который используют неподготовленные стороны.
*UML — язык графического описания для объектного моделирования в области разработки программного обеспечения, для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
*ArchiMate — это открытый и независимый язык моделирования архитектуры предприятия для поддержки описания, анализа и визуализации архитектуры внутри и за пределами бизнес-процессов однозначным способом.
Согласование словаря — огромная проблема. Использование разнообразных инструментов (что необходимо на практике) усложняет задачу. Согласовать все подразделения глобального бизнеса еще сложнее. Состояние отрасли оставляет желать лучшего. UML контролируется, но ограничен и сложен для понимания. ArchiMate контролируется слабо и концептуально неустойчив. TOGAF свободен и непоследователен.
ПРЕДПОСЫЛКИ СИСТЕМНОГО МОДЕЛИРОВАНИЯ
Чтобы избежать путаницы и согласовать архитектурные документы, используйте UML и ArchiMate — языки моделирования, созданные для описания структуры и работы сложных бизнес-систем. UML может быть сложным для изучения, но он представляет основы теории систем иначе, чем ArchiMate. Важно знать, что UML включает два основных принципа работы систем.
*Дискретность (от лат. discretus — разделённый, прерывистый) — свойство, противопоставляемое непрерывности, прерывистость.
- Все поведение управляется событиями, или дискретно.
- Все действия выполняются активными структурными элементами (называемыми активными объектами в UML; действующими лицами, компонентами и узлами в ArchiMate).
Можно выразить и расширить принципы UML с помощью понятий ArchiMate.
Инкапсуляция означает, что системы и действующие лица или компоненты помещаются в оболочку, называемую интерфейсом ввода-вывода.
Поведение описывает, как отдельные события запускают и выполняют стандартные модели действий в бизнес-системе.
Структура указывает на то, что действия в системе выполняются действующими лицами или компонентами, занимающими определённое пространство и требующими адресации.
Данные говорят о том, что объект данных содержит структуру данных или элемент, имеющий значение для создателей и пользователей.
Абстракция означает отделение системных описаний от существующих или планируемых операционных систем.
Типизация предполагает моделирование типов, а не конкретных экземпляров.
Благодаря этим факторам были разработаны, созданы и используются многочисленные бизнес-системы. Они служат основой для изучения принципов и проблем, описанных далее.
1. ИНКАПСУЛЯЦИЯ
Цель создания бизнес-системы — влиять на объекты и события вокруг неё. Описание бизнес-системы включает определение связи между системой и окружением. Разработчики начинают с определения внешних объектов и добавляют их в системную модель.
Принцип 1.1: Системы ограничены средой
Проще говоря, социальная, деловая или программная система заключена в оболочку, которая существует только в уме, а не в реальности. Эта таблица показывает, что внешний вид системы служит границей ввода-вывода, с которой работают внешние объекты. Внутреннее содержание системы отражает действия участников или компонентов, находящихся внутри этой оболочки.
Окружающая среда Внешние объекты и события Система Внешний вид События / Сервисы <представлены в> Интерфейсах Внутренний взгляд Процессы, <выполняемые> Участниками и компонентами
В некотором смысле система и связанные с ней внешние объекты объединяются, образуя более крупную систему. Но определение границ системы жизненно важно; оно говорит нам, что разработано системным разработчиком, а что нет.
Принцип 1.2: Системы являются вложенными и перекрывающимися
Системы устроены как матрёшки. Внешние и внутренние границы можно определить на любом уровне детализации системы. То, что кажется внешним для одной системы, может оказаться внутренним для другой. Каждый элемент системы можно рассматривать как отдельную систему. Эти элементы, функции и роли могут быть инкапсулированы и описаны предоставляемыми ими услугами. ArchiMate подчёркивает, что системы не только вложены, но и пересекаются. Элементы одной системы могут участвовать в процессах других систем.
Принцип 1.3: Существуют интерфейсы, привязанные к компонентам, и автономные интерфейсы
Интерфейс аппаратного устройства — это часть, которая помещает его корпус в трёхмерное пространство. Однако представление о мире через материальные объекты может ввести в заблуждение, поскольку действия людей и компьютеров распределены в пространстве.
Интерфейс к системе действий человека или компьютера логичен и может быть отделён от неё. Кажется, что пользовательский интерфейс является частью текстового процессора, но он также может предоставлять доступ к другим компонентам, таким как интерактивная справка, библиотека графических объектов или отчёты об ошибках.
Пользовательский интерфейс MS Outlook отделён от приложения MS Exchange. Сервис-ориентированная архитектура (SOA) предполагает отделение интерфейсов от компонентов, которые выполняют работу. Таким образом, компоненты и интерфейсы могут быть слабо связаны. Один интерфейс может быть реализован с использованием нескольких компонентов, и один компонент может реализовывать некоторые или все интерфейсы.
В ArchiMate есть разные обозначения для интерфейсов и компонентов. Поэтому архитекторы могут определить интерфейс, услуги которого предоставляются двумя или более внутренними элементами. Они также могут определить элемент, который предоставляет сервисы через два или больше интерфейсов. К сожалению, в ArchiMate есть три проблемы, связанные с отношениями между компонентами и интерфейсами:
- ArchiMate утверждает, что компоненты “состоят из” интерфейсов, а один интерфейс является частью одного и только одного компонента. Это отрицает возможность слабосвязанности между компонентами и интерфейсами.
- Если у компонента тот же адрес, что и у его интерфейса, то компонент является точкой доступа. В этом случае нет необходимости рисовать отдельные прямоугольники на схеме.
- Определение интерфейса ArchiMate ориентировано на предоставляемые интерфейсы, а не на требуемые интерфейсы. Предоставляемый интерфейс определяет услуги, которые система или компонент (действующий как сервер) предоставляет и может обслуживать клиентов. Требуемый интерфейс определяет службы, от которых зависит система или компонент (действующий как клиент) и которые делегируются серверам.
Принцип 1.4: бизнес-интерфейсы не являются каналами связи платформы
Социальная, деловая или программная система инкапсулируется логически, а не физически. Интерфейс «От субъекта к субъекту» или «от бизнеса к бизнесу» может быть определен в документе, в котором перечислены вызываемые бизнес-службы. Поскольку действующие лица и компоненты распределены, они должны обмениваться отдельными коммуникационными событиями, чтобы вызывать события и отвечать на вызовы. Также должен существовать физический канал связи, по которому могут передаваться коммуникационные события. В примерах ArchiMate наблюдается путаница между концепцией логического бизнес-интерфейса (объявляющего, какие службы могут быть вызваны) и каналами физической инфраструктуры, через которые могут быть вызваны службы.
2. ПОВЕДЕНИЕ
Основная идея теории систем заключается в том, что деятельность системы ограничена её окружением и происходит на границе между входом и выходом. Архитекторы изучают системы деятельности, анализируя повторяющиеся действия (процессы), которые выполняют участники и элементы (объекты) в ответ на определённые ситуации (стимулы).
Различие между структурой и поведением, фундаментальное для теории систем, кажется ясным на простых иллюстрациях.
Система Структурные элементы Поведенческие элементы Солнечная система планеты на орбите солнца Человеческое тело сердца, легкие и кожа дыхание, бег и потоотделение Бытовые услуги дворецкие, гости и столовое серебро приветствие гостей и полировка серебра Программное обеспечение интерфейсы, классы, объекты операции и взаимодействия
Однако иногда бывает сложно понять разницу между структурой и поведением. В определённом смысле, каждый активный элемент структуры обладает поведением, и каждое поведение имеет свою структуру. Роль или функции дворецкого определяются его действиями. Каждое действие дворецкого имеет свою логику и развивается со временем. Если убрать все действия из описания роли или компонента, останется только пассивная структура. Это похоже на ситуацию, когда из определения класса в UML удаляются все операции и остаются только типы данных.
Итак, как вы проводите однозначное различие между поведением и структурой? Различие, проводимое в UML, подкрепляется однозначными концепциями времени и пространства. Различие, проводимое в ArchiMate, основано на лингвистических концепциях субъекта, глагола и объекта; эти концепции более размытые и приводят к некоторой путанице при интерпретации стандарта ArchiMate.
Поведение 2.1: структура как различие во времени и пространстве
Физики утверждают, что наш мир находится в четырёхмерном пространстве-времени. Каждый элемент или субъект реагирует на информацию, основанную на его воспоминаниях, и выполняет соответствующие действия, получая поток вводных данных. Несмотря на то, что у каждого элемента есть свой «поток управления», его называют структурным элементом, потому что это структура, которую можно разместить в пространстве и заставить выполнять задачи с течением времени.
Общая теория систем утверждает, что система деятельности находится внутри своей среды и ограничена процессами ввода и вывода. Корпоративные архитекторы рассматривают системы деятельности, классифицируя их по
- регулярному поведению (повторяющиеся процессы во времени), выполняемому
- действующими лицами и компонентам (отдельные объекты в пространстве) в ответ на
- события (входные данные или триггеры).
Система Поведение с ограничениями по времени Адресуемые структуры Внешний вид События и результаты Границы ввода-вывода Внутренний взгляд Обычное поведение Действующие лица или компоненты
Поведение системы определяется входными данными и результатами, которые видят внешние объекты. Например, вы можете отправлять и получать электронные письма, не зная, как работает ваша почтовая система. Внешняя структура — это место, где внешние объекты могут запускать и просматривать результаты поведения. Приложение электронной почты имеет два интерфейса: один для людей, другой — для других программ. Таблица ниже — пример такой структуры.
Электронная почта Поведение с ограничениями по времени Адресуемые структуры Внешний вид Отправлять электронное письмо, получать электронное письмо Человеческий интерфейс, API Внутренний взгляд (невидимый) Приложение электронной почты
Разница между структурой и поведением заключается не столько в лингвистических особенностях, сколько в пространственно-временных различиях.
- Стандартные модели поведения в бизнес-системе запускаются отдельными событиями и развиваются со временем.
- Действия в этой системе выполняются участниками или элементами, занимающими определённое пространство и требующими адресации.
Принятие этих предпосылок приводит к созданию простой и надежной универсальной метамодели.
Система Поведение с ограничениями по времени Адресуемые структуры Что происходит, что делается Что можно найти для достижения цели Что видят внешние организации События и услуги Интерфейсы Внутренняя работа Процессы Действующие лица и компоненты
Общая теория систем предлагает рассмотреть поведение системы целиком. Проектирование системы начинается с определения нужного поведения, после чего подбираются, покупаются или создаются структурные элементы для выполнения этого поведения. В отличие от этого, анализ базовой системы TOGAF начинается с изучения существующих структурных компонентов и создания каталога услуг на их основе.
«Архиматический» взгляд на структуру и поведение
*SVO — типология порядка слов (в предложении) — один из методов типологической классификации языков, учитывающий базовый порядок слов в предложении: подлежащего (англ. subject), сказуемого (англ. verb) и прямого дополнения (англ. object).
Язык моделирования ArchiMate основан на грамматике предложений естественного языка SVO. В большинстве человеческих языков в предложениях используется последовательность SVO или SOV. Любопытно, что общая метамодель ArchiMate представлена в последовательности OVS. В таблице ниже приведены некоторые ключевые слова, используемые в языке моделирования ArchiMate, в соответствии со структурой OVS его общей метамодели.
Части естественного предложения Объект Глагол Тема Системные аспекты ArchiMate Пассивный структурный элемент Элемент поведения Активный структурный элемент Элементы системы ArchiMate Бизнес-объект, объект данных Сервис, процесс, функция Субъект, компонент, узел, интерфейс
Лингвистические концепции гибки. Не во всех предложениях есть подлежащее и объект. Одно и то же может быть и подлежащим, и объектом в одном предложении. Существительные используются как глаголы; глаголы используются как существительные. Вопросы, требующие изучения, включают в себя: Если мультисервисный компонент называется структурным, то почему мультисервисная функция (она же логический компонент) называется поведенческой?
В этой таблице показаны основные концепции общей метамодели ArchiMate.
ArchiMate Модели поведения Структуры Внешний вид Услуги Интерфейсы Внутренний взгляд Внутренние поведенческие элементы Внутренние активные структурные элементы
Словарь в таблице не очень удобен. Может, использовать вместо него другие термины, например, «действия» и «актёры», «представления» и «исполнители», «операции» и «операторы», «разработки» и «работники»? ArchiMate не может этого сделать, потому что не учитывает разделение на пространство и время. В следующей таблице представлены слова, которые ArchiMate использует для описания внешнего и внутреннего аспектов, а также поведения и структуры каждого уровня предметной области традиционной архитектуры.
Уровни архитектуры Модели поведения Структуры Бизнес-уровень Бизнес-сервис Бизнес-интерфейс Бизнес -процесс / функция Роль / Действующее лицо Уровень приложений Служба приложений Интерфейс приложения Прикладная функция Прикладной компонент Уровень инфраструктуры Инфраструктурные услуги Интерфейс инфраструктуры Функция инфраструктуры Узел
Классы с несколькими операциями в UML считаются структурными элементами, а операции представляют модели поведения. Однако в ArchiMate различие между структурой и поведением может быть неясным, возможно, из-за путаницы между структурой и поведением, а также между типом и экземпляром. Вместо этого ArchiMate опирается на различие между существительными и глаголами в естественном языке.Мы можем преобразовать любое существительное (например, брокер) в глагол (брокериг) без изменения архитектуры системы. Брокерство не является услугой в понимании ArchiMate, где функциональная единица должна иметь конкретный результат. Чтобы лучше согласовать ArchiMate с теорией систем.
Важно помнить, что все стандартные модели поведения в бизнес-системе запускаются отдельными событиями и выполняются со временем. Архитекторы предприятий придерживаются сервис-ориентированного подхода к бизнес-системам, где действующие лица и компоненты выполняют определённые действия в ответ на отдельные сообщения о событиях. Для определения деталей определённого поведения необходимо определить входные и выходные данные, предварительные условия, постусловия и нефункциональные характеристики (например, сервисный контракт или шаблон варианта использования).
Принцип 2.1: Тип события описывает схожие события, которые запускают поведенческие элементы.
Внешние события побуждают участников или компоненты изменять внутреннее состояние системы и / или предоставлять услуги. Некоторые службы / процессы не изменяют состояние системы. Некоторые события завершаются сбоем, некоторые запускают только службы / процессы отчетности. Если процесс, инициируемый событием, потребляет ресурс (скажем, электроэнергию), который не включен в модель системы, то такое изменение состояния выходит за рамки рассматриваемой системы.
WSDL — это язык определения интерфейса, используемый для определения “веб-служб”. Где разместить веб-службу в этой таблице?
Уровни архитектуры Модели поведения Структуры Уровень приложений Служба приложений Интерфейс приложения Прикладная функция Прикладной компонент
Вы могли бы представить веб-службу с помощью символа службы приложений ArchiMate, а Интернет — с помощью символа интерфейса приложения. Что на самом деле говорит стандарт ArchiMate? Интерфейс определяется как структура, предоставляющая одну или несколько служб, каждая из которых является функциональной единицей со своим собственным конкретным результатом.
- Поскольку ArchiMate определяет интерфейс, таким образом, веб-служба представляет собой точку доступа, где одна или несколько операций веб-службы открыты/доступны клиентам.
- Поскольку ArchiMate определяет сервис, то операция веб-сервиса — это единица поведения с определенным результатом, которую веб-сервис предоставляет своим клиентам, скрывая внутренние процедуры.
Уровни архитектуры Модели поведения Структуры Уровень приложений Работа веб -сервиса Веб -сервис Процесс подачи заявки Прикладной компонент
Использование ArchiMate и иллюстрации расходятся с его стандартными определениями концепции. Практика расходится с теорией систем, где, например, приложения обозначаются как ”сервисы“ (или «микросервисы”), интерфейсы обозначаются как “сервисы», каналы связи платформы обозначаются как “бизнес-интерфейсы”. Результатом является смешение структуры с поведением, путаница уровней архитектуры и потеря согласованности.
Если бы мы все согласились с тем, что услуга представляет собой отдельную единицу поведения, которая переходит от конкретного события к конкретному результату, то противоположные интерпретации термина “услуга” были бы маловероятны.
Некоторые предполагают, что службы, управляемые отдельными событиями, слишком детализированы, чтобы архитекторам стоило беспокоиться. Это вводит в заблуждение. Некоторые сервисы короткие и / или второстепенные; другие длинные и / или критически важные. На практике архитекторов интересуют важные сервисы. Если система или компонент предоставляет слишком много сервисов, чтобы их можно было отобразить на схеме, архитектор может объединить более короткие сервисы в более длинный сервис или иным образом объединить сервисы в кластеры. Но кластеризация сервисов создает логическую функцию / компонент, а не более крупную услугу.
ArchiMate не предполагает, что поведение зависит от событий, и размывает понятия события, процесса и изменения состояния. В нем говорится, что событие может начинаться или быть результатом поведения.
Принцип 2.1: Архитекторы моделируют несколько видов триггеров
В UML стрелка от поведения A к B является стрелкой перехода, она подразумевает передачу управления. В ArchiMate триггер от A к B может быть стрелкой перехода, а может и не быть. В нем описывается временная или причинно-следственная связь между экземплярами A и B. Означает ли это, что A останавливается, а B запускается? Нет. Там, где A и B являются грубыми функциями, это обычно означает, что какая-то часть внутри A запускает некоторый поведенческий элемент внутри B, и обычно имеется сопутствующий поток данных.