aeshnik


Уменьшая скорость роста энтропии вселенной


Previous Entry Share Next Entry
Архитектура предприятия в быту
aeshnik
Из лекций о специфике научного знания стало понятно, что деятельность неплохо бы рассматривать определенным способом: нужно помнить, что есть деятель, деятельность и объект деятельности.

В таком ключе довольно легко понимать, что ребята имеют в виду, когда пишут слово Process в умных книжка. Они имеют в виду не какую-то просто упорядоченную последовательность действий, они имеют в виду либо деятельность, направленную на создание какого-то объекта (по сути - на изменение какого-то объекта), либо деятельность, сгруппированную по каким-то общим признакам (необходимым знаниям и навыкам).
00.png

Рисовать блок-схемки с последовательностью действий (вроде бы как процесс) умеют почти все программисты, а обыденное познание, по идее, позволит описать последовательность действий любому. Но как бы еще указать, кто какую работу должен делать? Можно сказать, что Вася делает эту работу, а Петя - вон ту. А что делать, если Вася уйдет куда-то, а работу нужно делать?
01.png

Можно вместо Васи и Пети назначать на работы роли - некоторые места, которые может занимать Вася или любой другой человек с навыками и знаниями, достаточными для выполнения работы.
02.png

Осталось рассказать, какую информацию в результате работы нужно получить.
03.png

Это очень простая схемка. Однако, заметим, что про деятельность не все привыкли думать через эти три типа сущности. Некоторые, например, думают про деятельность только через объекты (или, что еще хуже, через документы). Нужно выпустить такой-то документ - вот и всё описание деятельности с их точки зрения. Но, в любом случае, как что-то описывать на этом уровне понятно. Это, можно сказать, архитектура бизнес-уровня. Архитектура, потому что мы связали объекты разного типа. Но на предприятиях сегодня обязательно есть что-то кроме бизнес-уровня.

Интересно, что на уровне программного обеспечения можно думать, используя такой же подход. Есть программа - субъект (исполнитель работы). У программы есть функция - она описывает поведение программы (работу). В результате исполнения функции программа выполняет какие-то действия с информационным объектом (программным объектом).
04.png

Как бы эти два уровня связать друг с другом? Они же довольно здорово похожи - думаем мы про них одинаково, типы объектов очень похожи. И действительно, это можно сделать. Роль использует программу через интерфейс (который содержится в программе). Функции программы реализуют сервис, который используется на бизнес-уровне для выполнения работы.
05.png

Это уже почти архитектура предприятия. Не хватает еще чего-то. Разного аппаратного обеспечения: компьютеров и программ, которые позволяют работать важным с точки зрения верхнего слоя программам.
Archimate 00.png

Эти картинки - представления модели. Так получилось, что эти представления каждое дополняет другое: нет в примере таких двух представлений, которые содержали бы одну и ту же сущность, но связанную с разными сущностями на разных представлениях. Но на самом деле такое бывает. И здесь нужно отметить, что не бывает единого представления чего-то. Представление модели формируется исходя из цели. Цель представления связана с целевой аудиторией представления. Кому-то интересно знать, в какую иерархию (оргструктуру) выстроены исполнители ролей. Кто-то интересуется только бизнес-уровнем, но хочет знать про субъект, деятельность и объект. А кому-то нужно представление информационной структуры (как соотносятся объекты с данными). Единого представления не бывает. Как и единой модели, но мы сейчас не об этом, мы останемся в рамках одной модели.

Архитектуру предприятия можно использовать для разного. Можно пытаться понять, какое оборудование поддерживает выполнение таких-то работ (например, чтобы улучшить это оборудование). Можно использовать для проектирования автоматизированных систем, связывая бизнес-слой со слоем предприятия. А можно показывать довольно сложные вещи просто, используя довольно примитивный (в сравнении с реальным миром уж точно) понятийный аппарат.

Скажем, у вас есть знакомый, который не понимает, как загружаются файлы из интернета. Вот так получилось, что на уровне обыденного познания ему это не ясно, и он испытывает трудности с загрузкой файлов. Или ему ясно на уровне обыденного познания, но он хочет систематизированных знаний. Вы предлагаете знакомому понятийную сетку (например, язык Archimate), и через эту понятийную сетку объясняете довольно-таки сложную штуку.
Archimate 02.png

Вуаля. Ваш знакомый всё понимает на том уровне детализации, на каком ему позволяет это понятийная сетка.

Ссылки по теме:
- моделлер Archi (бесплатный);
- книжка Mastering Archimate (космически крутая книжка, применимая на практике вот уже сейчас).

?

Log in

No account? Create an account