Архитекторы предприятий рассматривают предприятие как систему, каждый из модулей которой можно смоделировать с точки зрения ролей и процессов.
Внешняя организация - [Логический или физический компонент] вне интересующего бизнеса или системы, который взаимодействует с этим бизнесом или системой путем запроса или предоставления услуг.
Актер - [Физический компонент] или физическое лицо, способное играть одну или несколько ролей в выполнении процессов. (Если нечеловеческие субъекты представлены в виде прикладных и / или технологических компонентов, то действующие лица должны быть людьми.)
Организационное подразделение - [Физический компонент] или отдельный узел в структуре управления, способный выполнять одну или несколько функций. У него должны быть цели и задачи с мерами и менеджер.
Роль - [Логический компонент], реализуемый или используемый отдельными участниками, определяемый с точки зрения предоставляемых услуг и / или выполняемых процессов и требуемых способностей.
Функция - [Логический компонент], целостный набор моделей поведения, требуемых от любого подразделения организации, выполняющего функцию, определенную с точки зрения предоставляемых услуг и / или выполняемых процессов и требуемых способностей. (Это логическая бизнес-возможность, которую не следует путать с управляемой организационной единицей или отдельным бизнес-сервисом.)
Бизнес-процесс - [Процесс], который выполняется участниками бизнеса с использованием информационных технологий или без них.
Бизнес-сервис - [Услуга], которую можно запросить у бизнеса или его компонента. (Не путать с бизнес-функцией .)
Объект данных - [Элемент данных], состоящий из элементов данных, которые представляют факты о дискретном бизнес-объекте или событии. Он может быть задан на концептуальном, логическом или физическом уровне. Это может быть сопоставлено с хранилищами данных и / или потоками данных, вводимыми в службы ИБ или выводимыми из них.
IS - (приложение) сервис[Услуга], которая может быть запрошена у бизнес-ориентированного компонента приложения человеком-субъектом или другим компонентом приложения.
Прикладной компонент - [Компонент] бизнес-ориентированного программного обеспечения (например, CRM, биллинг). Логически это определяется предоставляемыми ИТ-службами, а иногда также объектами данных, которые оно поддерживает, и / или физически как продукт, специфичный для поставщика / технологии, который можно нанять, купить или создать.
Платформенный сервис - [Услуга], которая может быть запрошена у технологического компонента прикладным компонентом или другим технологическим компонентом.
Технологический компонент - [Компонент] общего программного обеспечения инфраструктуры (например, ОС, СУБД). Логически он определяется предоставляемыми им сервисами платформы и / или физически как продукт, специфичный для поставщика / технологии, который можно нанять или купить.
Корпоративные архитекторы моделируют динамические системы деятельности организации, информационно-зависимые процессы. Моделируют логическиепроцессы и потоки данных (т.е. роли и процессы), создающие и использующие данные, которые бизнесу необходимо отслеживать или направлять.
Проектируемые системы представляют собой зоны упорядоченного поведения. Бизнес-система (мебельная фабрика, маркетплейс, завод по производству автомобилей) — это зона стабильного и упорядоченного поведения в постоянно развивающейся истории предприятия. Мы можем смоделировать ее обычное поведение.
*Формализация — представление какой-либо содержательной области (рассуждений, доказательств, процедур классификации, поиска информации, научных теорий) в виде формальной системы или исчисления
Пример: Оглавление книги — это формализация её содержательных частей, а сам текст книги можно рассмотривать как формализацию по средством языковых конструкций мыслей, идей, размышлений автора. Итогом формализации научной теории является, как правило, совокупность формул, графиков,схем, таблиц и так далее.
То, что люди говорят и делают спонтанно, интеллектуально или творчески, может быть упомянуто в моделях бизнес-систем, но только как контекст работы, который можно формализовать и смоделировать в терминах регулярного поведения, управляемого событиями.
Архитекторы предприятий не являются социологами, архитекторы бизнес-систем моделируют не людей; они моделируют их распределение по ролям.
Социальные системы состоят из действующих лиц, которые общаются и выполняют действия в соответствии с полученными сообщениями и сохраненными воспоминаниями.
Бизнес-системы — это социальные системы, в которых роли формализованы, сообщения формализованы в потоках данных, память формализована в хранилищах данных, а действия выполняются в ответ на отдельные события.
Архитекторы предприятий и решений не строят самолеты, не разрабатывают новые лекарства, не проектируют производственные линии, не роют ямы на дорогах и не снимают фильмы. Они стремятся оптимизировать и интегрировать бизнес-роли и процессы за счет лучшего использования бизнес-информации, создаваемой этими ролями и процессами. Они не внедряют инновации в области машиностроения, биохимии или творчества. Они действительно ищут новые возможности для оцифровки и интеграции ролей и процессов, а также использования собранной информации.
Потребность в такой корпоративной архитектуре не нова, и она никогда не исчезнет.
Корпоративные архитекторы моделируют не все, чем является бизнес или что он делает. Они фокусируются на том, где физический (ручной, механический, материальный) мир соединяется с миром логической информации. О ролях и процессах, которые создают или используют информацию в ходе предоставления бизнес-продуктов и услуг. И об улучшении бизнес-операций за счет интеграции информации, создаваемой и используемой на предприятии.
СЛОВАРНЫЙ ЗАПАС КОРПОРАТИВНОГО АРХИТЕКТОРА
Как бизнес-система формализует социальную систему? Взаимоотношения между субъектами определяются через установление того, какие действия может вызвать сообщение, согласование смысла передаваемых сообщений и сохранённых воспоминаний.
Для формализации и интеграции поведения стороны должны согласовать значения символов, которые они создают и используют в сообщениях и памяти. Это в равной степени относится к людям, работающим в операционных системах, и архитекторам, моделирующим эти системы.
Естественный язык свободен и двусмыслен. Слова, которые мы используем для описания вещей, представляют собой вербальные кодировки нечетких ментальных моделей.
Русский язык насчитывает более 200 000 слов, разные слова имеют одинаковое значение, а одно слово имеет несколько значений. Например: является ли “сервис” типом процесса, экземпляром переходного процесса, постоянной функцией или ролью, отвечающей за различные типы процессов и экземпляры? Чем это отличается от ”функции“ или «роли”?
Это не беспокоит нас в повседневных обсуждениях. Но профессиональная спецификация бизнес-систем — это совсем другое дело. Если графические символы в языке системного моделирования представляют собой просто слова, поскольку люди используют их естественным образом, то язык моделирования будет таким же большим, расплывчатым и двусмысленным, как и естественный язык.
Естественно, мы не используем слова логичным и упорядоченным образом. Тем не менее, это именно то, к чему мы стремимся при описании формализованных систем, которые должны быть построены, развернуты и использоваться другими. Профессиональным системным архитекторам необходим контролируемый словарный запас. Язык описания бизнес-систем должен строго и недвусмысленно различать типы системных элементов (таких как сервис, функция и интерфейс), чтобы архитекторы бизнес-систем могли использовать их согласованным образом и легко понимать друг друга.
Профессиональный язык моделирования систем должен быть более дисциплинированным, чем естественный язык. Это должно помочь архитекторам описывать участников системы и действия, используя небольшое количество символов / слов – значение которых не двусмысленно, чтобы избежать расплывчатости естественного языка. Профессионалам, возможно, придется переводить свои модели на любой естественный язык, который используют неподготовленные стороны.
*UML — язык графического описания для объектного моделирования в области разработки программного обеспечения, для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
*ArchiMate — это открытый и независимый язык моделирования архитектуры предприятия для поддержки описания, анализа и визуализации архитектуры внутри и за пределами бизнес-процессов однозначным способом.
Согласование словаря — огромная проблема. Использование разнообразных инструментов (что необходимо на практике) усложняет задачу. Согласовать все подразделения глобального бизнеса еще сложнее. Состояние отрасли оставляет желать лучшего. UML контролируется, но ограничен и сложен для понимания. ArchiMate контролируется слабо и концептуально неустойчив. TOGAF свободен и непоследователен.
ПРЕДПОСЫЛКИ СИСТЕМНОГО МОДЕЛИРОВАНИЯ
Чтобы избежать путаницы и согласовать архитектурные документы, используйте UML и ArchiMate — языки моделирования, созданные для описания структуры и работы сложных бизнес-систем. UML может быть сложным для изучения, но он представляет основы теории систем иначе, чем ArchiMate. Важно знать, что UML включает два основных принципа работы систем.
*Дискретность (от лат. discretus — разделённый, прерывистый) — свойство, противопоставляемое непрерывности, прерывистость.
Все поведение управляется событиями, или дискретно.
Все действия выполняются активными структурными элементами (называемыми активными объектами в UML; действующими лицами, компонентами и узлами в ArchiMate).
Можно выразить и расширить принципы UML с помощью понятий ArchiMate.
Инкапсуляция означает, что системы и действующие лица или компоненты помещаются в оболочку, называемую интерфейсом ввода-вывода.
Поведение описывает, как отдельные события запускают и выполняют стандартные модели действий в бизнес-системе.
Структура указывает на то, что действия в системе выполняются действующими лицами или компонентами, занимающими определённое пространство и требующими адресации.
Данные говорят о том, что объект данных содержит структуру данных или элемент, имеющий значение для создателей и пользователей.
Абстракция означает отделение системных описаний от существующих или планируемых операционных систем.
Типизация предполагает моделирование типов, а не конкретных экземпляров.
Благодаря этим факторам были разработаны, созданы и используются многочисленные бизнес-системы. Они служат основой для изучения принципов и проблем, описанных далее.
