Системное проектирование и анализ альтернатив за три минуты

Архитектор решений (solution architect) работает с тремя группами специалистов:
1. С бизнес-аналитиками
2. С системными аналитиками
3. С разработчиками

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

Вам нужно решение, вам нужен сервис быстрого передвижения потому что связка машина + общественный транспорт не справляется.

Анализом проблемной области заказчика занимаются бизнес-аналитики. В результате своей работы они выдают верхнеуровневое описание того, как должны выглядеть поездки после реализации проекта улучшения. Они описывают контекст проблемы - поездки по району, поездки между районами, поездки на работу в часы пик, поездки по выходным, поездки в плохую погоду и зимой. И говорят - нужен такой-то сервис. Чтобы было модно-стильно и молодежно, называют свою презентацию Urban Mobility Solutions и выдают технико-экономическое обоснование, где говорится, что решение не должно стоить дороже 40 т.р., обслуживание не должно быть дороже 2 т.р. в год, срок службы должен составлять минимум 42 месяца, а пользоваться решением вы должны не меньше, чем 230 дней в году.

И тут вступают в дело архитекторы. Они начинают искать как можно принципиально реализовать такие сервисы. И выясняют, что есть несколько принципиально подходящих классов решений:
- Велосипеды
- Ролики
- Скейты
- Самокаты
- Электросамокаты
- Моноколеса
- Гироскутеры

Так как вам надо ездить на работу, то ролики отпадают, смешно ехать в рубашке с галстуком на роликах по улице. Скейты отпадают по той же причине. Самокат не устраивает т.к. не годится для езды в горку и при езде на нем можно вспотеть, особенно летом. Гироскутеры заказчика не устраивают по внешнему виду, и остаются три альтернативы - велосипеды, электросамокаты и моноколеса. И начинается архитектурное проектирование.

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

Проблема архитектора в том, что бизнес-аналитики сказали заказчику, что ему нужны сервисы городской мобильности, и заказчик согласился. Но и велосипед и самокат и моноколесо реализуют один и тот же сервис - доставляют из точки А в точку Б на небольшие расстояния. В чем же между ними отличия, которые повлияют на архитектурный выбор?

Системное проектирование находится на зыбкой грани между разработкой совсем уж концептуальных схем транспортных средств и их конкретной технической реализацией. Например, если говорить предельно абстрактно, то функция велосипедов разбивается на две - удержание равновесия и движение вперед за счет кручения педалей. Равновесие удерживается в основном за счет подруливания. Самокат похож на велосипед, но тут не надо крутить педали, равновесие удерживается за счет как подруливания так и наклона вертикального корпуса. Как видим, и в том и в другом случае для езды нужны обе руки потому что есть руль.

Моноколесо - отдельный вид решения. Езда на нем - это постоянное падение корпусом вперед. Это очень похоже на то, как спутники на орбите летают, все время падая, но не падая (поэтому на орбите и есть невесомость, потому что все всё время падают). Но если корпус падает вперед, а ноги на платформе едут с такой же скоростью, как падает корпус, то получается равномерное контролируемое движение. В схеме моноколеса есть два принципиальных решения - гироскоп удерживает его в вертикальном положении, не дает заваливаться набок и вперед, и мотор удерживает скорость постоянной неважно едете вы в горку или под горку. В этом отличие моноколеса от велосипеда и самоката. Если ноги на платформе будут неожиданно ускоряться или замедляться, то контролируемое падение превратиться в неконтролируемое.

Выбор схемы движения и способа удержания равновесия и есть первое принципиальное решение, которое надо принять в проекте. Но как вовлечь в такое решение заказчика? Какое ему дело до всей этой физики-математики? И в дело вступают системные аналитики. Они начинают выяснять, а какие же конкретно сценарии для клиента открываются в случае реализации проекта по каждой из архитектур. Например, на самокате он уже умеет ездить, переучиваться не надо. Это существенный плюс в пользу такого решения. Зато на моноколесе свободны руки, можно звонить по телефону без гарнитуры, ездить по навигатору без держателя на руле, пить кофе на ходу. А на велосипеде можно переезжать бордюры. Все эти принципиальные характеристики решений можно свести в одну таблицу и представить заказчику, пусть решает.

И заказчик смотрит во вторую версию презентации Urban Mobility Solutions и принимает еще одно решение. Он хочет моноколесо. И за дело принимается уже вся команда - и бизнес-аналитики и системные аналитики и архитектор решения и руководитель проекта.

Они анализируют возможные варианты реализации моноколес, уточняют характеристики, цвет, емкость аккумуляторов, скорость зарядки, скорость, цену, особенности эксплуатации, вопросы провоза их на самолетах и поездок в час пик, вопросы техобслуживания и ремонта, прописывают конкретные сценарии езды и снимают обучающие ролики по хитростям и приемам.
Все для того, чтобы заказчик после покупки не просто получил сервис Urban Mobility, но и смог решать свои конкретные задачи в конкретных условиях, а не обнаруживал на своем горьком опыте, что попытка переехать через невысокий бордюр с горячим кофе может закончиться конфузом. Потому что решаемые системой цели и задачи - это не то же самое, что функции и сервисы. Приобрести техническое решение, его надо освоить и встроить в свои практики.

Это очень упрощенный взгляд на то, чем реально занимаются системные архитекторы в технологических проектах, но принципиально все именно так. Они строят мостик понимания, осознанного выбора от абстрактных верхнеуровневых схем и концепций к конкретным техническим решения, воплощенным в "железе" и коде.

Дырка от бублика как системный интерфейс (PRINCE 4.0*)

*фреймворк Projects IN Chaotic Environment, версия 4.0

У меня есть знакомая, которую зовут, допустим, Анна. Она работает за пятерых - за руководителя направления, руководителя проекта, тимлида, системного архитектора и наполовину за закупщика и сисадмина. И как-то она выдала фразу: "Программа, которую я пишу, спокойно может отказаться делать свою работу, если ей поставить задачу неправильно или если она перегружена, а я все беру и беру на себя, все тащу и тащу". И действительно, софт или "железка" спокойно откажутся работать там, где люди возьмут на себя непосильные обязательства. Из-за этих непосильных обязательств, которые не выполняются или выполняются только частично, получается так, что машины намного надежнее, чем люди. В результате куда больше людей верят своим смартфонам, чем другим людям.

Рисунок 1. Данные по технооптимизму в России, исследование Евробарометра

Машины надежнее людей потому что их работа описывается достаточно точными моделями. Без четкого понимания того, как машина работает, ее просто нельзя создать и отладить. Чтобы машина или программа работала, надо четко описывать то, какие задачи и как она получает и какие результаты, как и куда выдает.

Чтобы поставить задачу системе, надо выдать ей корректное задание в правильном месте - на интерфейсе, API или в экранной форме, с использованием протоколов обмена информацией, плюс она еще и уровень доступа у вас проверит, а можете ли вы вообще ей задачи ставить. Выполнение задачи забирает ограниченные ресурсы системы, нельзя навалить сто задач и требовать, чтобы все это было сделано сию же минуту. Если системе не выдать абсолютно понятного ей задания, или у нее ресурсов не хватает, она просто ничего не сделает и ей даже стыдно не будет. Человеку же дать задание намного проще - достаточно остановить в коридоре на 15 секунд и что-то быстро надиктовать, зачастую даже проверки прав на доступ не происходит, на чем живут многочисленные продавцы по телефону и мошенники. А дальше человек сам справляется с потоком непонятно каких задач непонятно от кого, как Анна. До какого-то момента справляется, пока ресурсы не кончатся. У кого-то их много, и он тянет долго, у кого-то их меньше, и они выгорают раньше. Если только не перепоручать выполнение другим. Но тут есть ряд проблем.

Проблема Анны в том, что она не может дальше перепоручить ничего из своих дел, потому что все задачи слишком слабо формализованы и только она знает, что, как и когда делать. На передачу дела уйдет уйма времени, больше, чем на то, чтобы сделать самой.

Но необязательно так страдать от чрезмерной нагрузки, достаточно правильно построить орг.дизайн в своих проектах. И один из ключевых шагов в построении правильного орг.дизайна заключается в том, что надо перенести понятие системного интерфейса на взаимодействие людей. Достаточно начать правильно рассуждать о бизнес-процессах, организационных ролях, организационных единицах и организационных интерфейсах. И тогда не будет ситуации, которую описал Виктор Вахштайн, исследователь, который формирует результаты Евробарометра в России. На вопрос «Как вы считаете, люди действительно такие откровенные сволочи, какими кажутся?», подавляющее большинство россиян отвечает «И еще хуже!». (https://www.dv.kp.ru/daily/26739/3767213/)

Аннотация

Понятие интерфейса в культуре значительно уже и конкретнее понятия системного или организационного интерфейса в системном подходе 2.0. В этой статье я разбираю основные ошибки в мыслительных ходах по поводу системных интерфейсов, которые допускают люди, изучающие системный подход. Кроме того, я привожу примеры, когда более абстрактное понимание интерфейса приводит к переосмыслению подхода к цифровизации и внедрению ИТ-систем, в особенности про создании киберличностей и киберорганизаций.

Статья описывает часть фреймворка PRINCE 4.0 - Projects in Chaos Environment.

Ключевые слова: ограничения системной инженерии, трансдоменные объекты, организационные интерфейсы, архитектура предприятия

Интерфейс или его имплементация?

1. Если попросить разработчика ПО сделать пользовательский интерфейс, то он нарисует форму, настроит вывод данных в эти формы, проверит, что все работает и сдаст работу. Для него все просто - интерфейс отображается на экране.

Рисунок 2. Обычное представление об интерфейсе

Качество интерфейса - это его понятность, простота использования, в целом способность работать с системой. Другими словами, интерфейс является основной причиной взаимодействия программы и пользователя. Есть интерфейс - взаимодействие происходит, нет интерфейса - взаимодействия не происходит. Причина (интерфейс) есть - есть следствие (работа пользователя с программой), нет причины (интерфейса) - нет следствия (работы).

2. А теперь проведем мысленный эксперимент. Есть экран, на котором показан пользовательский интерфейс. И представим, что на него смотрит человек со слабым зрением, которые не понимает язык интерфейса и логики работы программы. Реализация интерфейса на стороне программы не изменилась, пользовательский интерфейс программы точно такой же, но взаимодействия между программой и пользователем не происходит. Интерфейс не выполняет свою задачу, не обеспечивает взаимодействие. Если спросить разработчика в чем дело, он скажет, что к программе предъявлены неправильные требования. Другими словами, требования к системе предъявляются на интерфейсе.

Рисунок 3. Требования и интерфейсы

3. А вот с точки зрения системного инженера ситуация выглядит немного по другому. Системный инженер (СИ) всегда задает себе вопросы - а откуда пришло это требование, почему оно именно такое, можно ли его ослабить или наоборот, оно слишком мягкое и даже если его выполнить, то система будет работать неустойчиво? Чтобы ответить на эти вопросы, СИ делает особый мыслительный ход, который называется метасистемным переходом. Он видит в этой ситуации не одну систему, а три - программу, которая работает на компьютере (1), пользователя, который взаимодействует с интерфейсом программы (2), и надсистему, которая их объединяет - пользователя, чьи способности усилены компьютером и программой (3).

Рисунок 4. Взгляд системного инженера на интерфейс

4. Такой мыслительный ход может большинству разработчиков и аналитиков показаться пустым умствованием и переусложнением, но на практике этот взгляд бывает крайне продуктивен. В частности, если речь идет о построении сложных систем или организации бизнес-процессов в хаотичных средах. Отступление для тех, кто погружен только в софт 

В разработке софта интерфейсный модуль, то есть какой-то компонент, который обеспечивает взаимодействие составных частей программной системы, можно создать один раз и потом вставить во все программные модули, которые этот интерфейс используют. Поэтому классический перекос мышления у разработчиков ПО в том, что они часто воспринимают все интерфейсы через призму такой однократной реализации. Но на примере пользователя, который работает с пользовательским интерфейсом программы, видно, то интерфейс появляется как результат взаимодействия двух процессов сопрягаемых систем. Процесса отображения интерфейса на экране со стороны программы и процесса восприятия изображения со стороны пользователя. Если любой из процессов исчезает, останавливается, то и интерфейс исчезает. 

Проведем другой мыслительный эксперимент. Пользователь сидит и работает с программой, у него все хорошо. Но тут он начинает уменьшать яркость монитора, уменьшает ее до минимума, перестает видеть экранные формы и не может работать дальше. С программной реализацией интерфейса ничего не случилось, она все та же, но интерфейс исчез, взаимодействие процессов отображения и восприятия остановилось. Аналогично мы можем не менять яркость монитора, а просто раскрыть плотные шторы или жалюзи в яркий солнечный день и вытащить монитор на прямой солнечный свет. Пользователь опять ничего не увидит и работающий интерфейс исчезнет.

5. Интерфейсы реализуются (имплементируются) несколькими составными частями системы, не существуют вне взаимодействия этих составных частей и зависят от контекста. 

6. Отсюда вытекает важнейший вывод для орг.дизайна - не надо думать, что процессная модель должна покрывать всю деятельность подразделения от получения задания на вход до поставки готового результата. Куда важнее описать четкую реализацию, имплементацию орг.интерфейсов, интерфейсных частей процессов. Регламентировать в первую очередь надо не исполнение функции, а сервисы, которые бизнес-процессы оказывают друг-другу, обеспечивают их взаимодействие.

Рисунок 5. Схема имплементации орг. интерфейса

7. Мысленный эксперимент: представим, что наша компания заключила договор на оказание консультационных услуг. Договор - это описание, спецификация организационного интерфейса. Чтобы договор заработал, чтобы образовался орг.интерфейс, с нашей стороны должен появиться процесс формулирования и доведения задачи до исполнителя и изменения постановки и приемки результата. А со стороны консультанта должен появиться процесс приемки задачи, отчета о ходе исполнения и предоставления готовых результатов. Сам орг.интерфейс как дырка от бублика, существует между этими процессами, в тот момент, когда они взаимодействуют. Еще раз подчеркну, что интерфейс существует только тогда, когда взаимодействуют процессы на стороне заказчика и исполнителя. Если человек заболел или уволился, а замены ему нет, то интерфейс исчезает, контракт перестает работать. 

8. Другой момент, который постоянно пропускают в процессных моделях, заключается в описании тех контекстов, в которых интерфейсные части процессов остаются функциональными. Вообще, формальное описание процессов, бюрократизация, позволяет масштабировать организационные системы. Но с масштабированием неизбежно происходит смена контекста и работающие орг.интерфейсы, возможно, теряют свою функциональность. Этот эффект часто наблюдается внутри больших корпораций - процесс, эффективно работающий в одной части организации перестает работать в другой даже если люди обучены, ИТ-системы внедрены, регламенты написаны. 

Академическое замечание "Интерфейс как причина" 

Подчеркну то, что интерфейс входит в каузальную цепочку взаимодействия составных частей системы. На практике это означает, что если интерфейс сопрягает две функции, два процесса работы двух составных частей системы, то какое-то изменение параметров одной сопрягаемой функции должно приводить к изменению параметров другой сопрягаемой функции. 

Например, хотя все телефоны, планшеты и компьютеры в доме подключены к одной Wi-Fi сети и получают постоянно один и тот же физический сигнал, сопрягаются они только в тот момент, когда передаваемые данные предназначены для них, имеют четкий синтаксис и соответствуют спецификации. И тогда поведение роутера и сетевой карты связаны алгоритмом, логикой, причинно-следственными связями. 

9. Процессные менеджеры зададут вопрос - а что же тогда находится в оставшейся части бизнес-процесса? Что происходит после того, как задача, материалы, рабочие продукты прошли через имплементацию интерфейса? Мой ответ близок к пониманию бизнес-процессов в варианте Rummler and Brache, Managing the white space и Jan Dietz, Enterprise ontology - внутри бизнес-процессов, ограниченные орг.интерфейсами, находятся практики. И одна из основных ошибок при проектировании процессной модели заключается в том, что в моделях процессов одними и теми же методами описания прописывают как интерфейсы так и практики.

Рисунок 6. Процессные имплементации орг. интерфейсов и практики

Даже в блестящем докладе Филиппа Дельгядо "Методология как конструктор: инструкция по сборке" орг.интерфейсы не выделены как объекты первого рода, хотя у меня есть гипотеза, что при анализе матрицы плотности методологии А. Коуберна формальность описаний процессов касается в первую очередь имплементаций интерфейсов, но не самих практик преобразования одних артефактов в другие.

Интерфейс как абстрагирование от деталей реализации и проблема дырявых границ системы

10. Интерфейс не только сопрягает, но и изолирует подробности реализации, позволяет абстрагироваться от деталей, ограничить распространение ошибки. Применительно к орг.интерфейсу это означает, что нам необязательно знать исполнителей, нам должны быть известны только роли, которые исполняются практики бизнес-процесса, и которые отвечают за интерфейс. И здесь всплывает интересный момент, связанный с ассистентами и SPOC, single point of contact. Фактически, и те и другие - это роли, которые занимаются только имплементацией интерфейсов. Другими словами, есть организационные единицы - предприятия, организации, бизнес-подразделения, дивизионы, отделы, интегрированные продуктовые команды, комитеты, рабочие группы, цеха и другие формальные и неформальные объединения ролей, и процессы с их имплементацией интерфейсов помещаются в контейнер организации. А ассистенты, SPOC и менеджеры по работе с клиентами выполняют все процессы имплементации

11. Поэтому так важно прописывать меморандумы о взаимопонимании, соглашения о взаимодействии или уровне сервиса - это, фактически, определяет требования к роли, которая будет обеспечивать имплементацию интерфейса. Что часто пропускают в SLA так это указания на то, орг.интерфейсы каких процессов реализуются исполнителем роли SPOC, ассистента или менеджера клиента. Куда, в какие процессы он обязан выдавать информацию? Опять мы видим подход - у Анны голова большая, пусть думает. В результате абстрагированная до задерганного, ничего не понимающего менеджера, компания выглядит не самым лучшим образом.

12. Со стороны клиента ваш процесс хорош ровно настолько, насколько хорош его орг.интерфейс. Возьмите пример МФЦ - практически без изменения практик добились качественного улучшения обслуживания, поменяв орг.интерфейсы.
Но при назначении исполнителей на роль SPOC зачастую игнорируют ключевое требование к интерфейсу. Интерфейс должен ограничивать распространение ошибки, не пропускать внутрь и не передавать наружу некорректную информацию. Это требует особых навыков у исполнителя, которые отдельно редко обсуждаются и поэтому исполнители роли SPOC не полностью реализуют возложенный на них объем интерфейсной работы. А если еще вспомнить про проблему потери интерфейсом функциональности из-за переноса в другой контекст, то ситуация осложнится и дальше. Ведь для переноса знаний в новый контекст необходимо понятийное мышление, которое есть у очень немногих людей. Словом, для таких позиций нужен особый набор мыслительных практик и навыков, который, как мне кажется, сейчас слабо осмыслен, координатор или ассистент считается проходной позицией с низкими требованиями, хотя эта роль является архитектурным элементом организационно-технической системы предприятия.

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

В каком мире существует интерфейс?

14. Итак, интерфейсы с одной стороны существуют, раз они являются частью причинно-следственных связей составных частей системы, а с другой, ни в одной спецификации вы не увидите таблицу с составом и строчку "Интерфейсы USB 2 шт." Так что они вроде как и нематериальны, их нельзя купить, заказать, установить, они появляются в момент функционального сопряжения нескольких действующих объектов, составных частей системы или системы систем.

15. Как такое может быть? неплохое объяснение сути интерфейсов дает акторно-сетевая теория.

Дальше цитата по:
Ло Дж. Объекты и пространства // Социология вещей / Под ред. В. Вахштайна. М.: Территория будущего, 2006. C. 30–42.
Вахштайн В., Три «поворота к материальному»

«Корабль, — пишет Ло, — может быть представлен в виде сети — сети остовов, рангоутов, парусов, канатов, пушек, складов про довольствия, кают и самой команды. С другой стороны, при более обобщенном рассмотрении, навигационная система, со всеми ее эфемеридами, астролябиями и квадрантами, таблицами расчетов, картами, штурманами и звездами, также может быть рассмотрена как сеть. Далее, при еще более отстраненном анализе, вся португальская имперская система в целом, с ее портами и пакгаузами, кораблями, военными диспозициями, рынками и купцами может быть описана в тех же категориях» [Ло 2006: 224].

В данном описании все предметы исследования рассматриваются как «объекты» — корабль, навигационная система, португальская империя. Объектами их делают устойчивые связи и отношения друг с другом. Особый акцент на устойчивости: «Штурманы, противники-арабы, ветра и течения, команда, складские помещения, орудия: если эта сеть сохраняет устойчивость, корабль остается кораблем, он не тонет, не превращается в щепки, напоровшись на тропический риф, не оказывается захваченным пиратами и уведенным в Аравийское море.

Он не пропадает, не теряется, до тех пор пока команда не сломлена болезнями или голодом. Корабль определяется своими отношениями с другими объектами, и акторно-сетевой анализ направлен на исследование стратегий, которые производят (и, в свою очередь, произведены) этой объектностью, синтаксисом или дискурсом, определяющими место корабля в сети отношений» [Ло 2006: 227]. Разрыв сети отношений кладет конец дискретной объектности.

Как объект, корабль пространственно или топологически множественен: «Он занимает — а также преобразует — два типа пространства. Географическое и семиотическое (сетевое)». Он неизменен в каждой из форм пространства и сохраняется в обоих: физически — в географическом пространстве, функционально или синтаксически — в семиотическом (сетевом) пространстве. Двигается он только в географическом пространстве. Напротив, в пространстве сетей он неподвижен, никакого изменения отношений между компонентами не происходит. (А если происходит, значит, что-то не так, значит, это уже другой объект.) Именно неподвижность в сетевом пространстве делает возможным его перемещение в пространстве географическом, позволяя переплывать из Калькутты в Лиссабон с грузом специй. Перемещение из точки А в точку В некоторого объекта происходит благодаря устойчивости отношений между различными элементами сети, в которой этот объект находится. Если произойдет смещение в пространстве сетей (т.е. если изменятся конституирующие объект отношения), корабль просто перестанет быть «кораблем Х с грузом Y, следующим курсом Z», а станет чем-то иным: обломками корабля, Летучим Голландцем или просто деревом для костра.

16. С точки зрения системной инженерии семиотическое пространство (пространство знаков, описаний) - это и есть пространство, где существуют интерфейсы. Скажем, если пользователь только-только купил телефон и начал им пользоваться, еще не создал для себя интерфейсов к нему. Есть только имплементация интерфейса со стороны телефона. Это очень четко видно на сложных автоматизированных системах, которые сдаются вначале в опытную эксплуатацию (transition stage), и только потом в промышленную. Сложная автоматизированная система изначально не вписана в пространство смыслов ее оператора, она не функциональна без обучения, тренингов, сопровождения, у нее нет интерфейсов. Пока сопрягаемая система не сможет запустить на своей стороне процессы, которые реализуют вторую половину интерфейса, он сам не появляется. Чем лучше освоены системные интерфейсы, чем ближе к архитектурному замыслу они работают, тем больше функциональных возможностей у системы. В англоязычной литературе это называется 'capabilities acquisition', на русском "освоение", "использование по назначению".

17. Итак, интерфейс имеет двойственную природу - с одной стороны он материален и существует одновременно как часть двух или более искусственных или естественных систем. Никакой другой объект системной инженерии не обладает больше таким свойством, любой материальный объект является составной частью только одного другого, более высокого системного уровня, это основной принцип управления составом системы. А с другой стороны, несмотря на материальность, он не изготавливается и не приобретается.

18. Название статьи "Дырка от бублика" намекает именно на то, что мы не изготавливаем дырку от бублика отдельно, она появляется как результат изготовления бублика. И чтобы сделать хороший бублик, надо четко указать какая именно дырка должна в нем быть. Аналогично, мы не изготавливаем интерфейсы, но зато пишем на них подробную документацию, потому что дырка от бублика очень важная часть бублика. В системной инженерии идейная проработка системных интерфейсов идет со старта проекта и на ранних этапах фиксируется в документе "Операционная концепция", Concept of Operations.
19. Из этого свойства дуальности интерфейса следует два вывода:

Вывод первый - интерфейс позволяет рассматривать всю систему или ее составную часть как черный ящик, скрывать детали реализации за фасадом интерфейса. И, значит, предъявлять требования к системе и проверять исполнение этих требований следует именно на интерфейсах, оставляя реализацию требований за разработчиком. А таблички трассировки требований должны быть иметь столбец "Интерфейс".

Вывод второй - если нам надо автоматизировать интерфейсные объекты, у нас большие проблемы, так как существующие подходы к построению автоматизированных систем подразумевают материальность проектируемых и создаваемых систем, наличие целевой системы и ее жизненного цикла. Но есть целый класс ИТ-систем, которые не моделируют целевые системы, так называемые трансдоменные объекты, boundary objects. И попытки создать трансдоменные объекты с помощью методов разработки автоматизированных систем на мой взгляд обречены на неудачу. Поэтому критически важно на старте проекта понимать, к какому классу относится система и не использовать методы системной инженерии, пусть хоть и в варианте ГОСТ 19 и ГОСТ 34, для создания трансдоменных объектов на базе ИТ-систем.

20. Подводя промежуточный итог, как проверить, является ли штука интерфейсом:
- Не изготавливается
- Является частью минимум двух искусственных или естественных систем
- Позволяет сформулировать и проверить на нем предъявляемые к системе или ее составной части требования для любой, частью которой он является.

Проверьте по этому чек-листу то, что вы сейчас называете интерфейсом, и вас ждет много открытий. Подумайте, где же у вас на самом деле интерфейсы.

Трансдоменные объекты

21. Проблему информационной безопасности, дырявых границ социально-технических систем и перегрузки ресурсов исполнителей можно начинать решать, если коммуникация будет организована через трансдоменные объекты. Но прежде чем перейти к рецептам, надо ввести это понятие в область обсуждения.

22. Ключевым понятием системного подхода является целевая система. Она является точкой отсчета всех системных построений.

Рисунок 7. Продуктовый крест системы ERP

Про целевую систему читайте учебник "Системное мышление 2019" А. Левенчука, проходите его онлайн курс: https://system-school.ru/sm2019
Дальше я подразумеваю, что вы знакомы с этим понятием.

23. У вашего предприятия есть целевая система, и в автоматизированных системах отражается ее жизненный цикл. На рисунке выше показан продуктовый крест (совместная модель жизненного цикла проектируемой ИТ-системы и жизненного цикла целевой системы), целевой системой проекта разработки и внедрения ERP является продукция, а в ERP отражается часть жизненного цикла этой продукции. Можете посмотреть неплохую презентацию Криса Партриджа на тему информационного моделирования (Ontology-Driven Re-engineering of Business Systems Tutorial CAiSE 2013 19th May 2013 Chris Partridge and Sergio de Cesare, аннотация здесь http://www.borosolutions.net/sites/default/files/CAiSE2013%20-%20Tutorial%20-%20Ontology-Driven%20Re-engineering%20of%20Business%20Systems%20(abstract).pdf), она проясняет важные моменты по теме информационного моделирования деятельности предприятия.

24. Вкратце, содержимое ИТ-систем описывает какую-то деятельность по созданию целевых систем и системная инженерия в своих методах опирается на допущение, что целевая система есть, а именно по поводу нее происходит координация деятельности. Если целевая система выбрана неверно, то применение системной инженерии приводит к некорректным результатам, т.к. при неправильном выборе целевой системы логика системного подхода очень быстро разваливается и команда возвращается к шагу один и пытается выявить целевую систему. Иногда такие циклы крутятся много раз и не приводят ни к чему. В таких ситуациях в качестве некой "затычки" и "обходного маневра", 'workaround' в фреймворке системного мышления целевой системой объявляется "нейронные сетки человека", см., например https://ailev.livejournal.com/1504570.html

25. Слабость такой концептуализации сразу всплывает, если задать вопрос: "А разве нейронные сетки мозга можно спроектировать, задать их целевую конфигурацию, спланировать производство их составных частей, сборку, функциональное сопряжение?" Ответ на этот вопрос однозначный: "Нет, нельзя". И подобная концептуализация фундаментально слаба, в ней отсутствует прагматический аспект - словом, прикольно, но бесполезно. Зато трансдоменный объект, который вызывает у целевой аудитории, у нужных нам проектных ролей, рост нейронных сеток (аксональное наведение или neuronal cone growth см. Growth Cones-turning and actin dynamics.m4v) - это вполне проектируемый и создаваемый инженерный объект. Он может заменять понятие "целевой системы" в ситуациях, когда ее выявить невозможно.

26. Приведу пример слабости концепта целевой системы в некоторых инженерных проектах. Что является целевой системой Фейсбука или Miro? Или экземпляра SAP в филиале, который настроен только на подачу нужной отчетности в головной офис, при том, что в компании есть и рабочий экземпляр SAP, где отражены факты хозяйственной жизни, часть жизненного цикла целевой системы предприятия? В проекте по созданию фейковой управленческой отчетности нет какого-то целевого состояния мира, какой-то приобретаемой предприятием в результате внедрения ИТ-системы орг. способности. Орг.способность, которая приобретается в результате такого внедрения, не продвигает целевую систему по жизненному циклу. Она полезна, несет ценность, но не работает на целевую систему и потому системный подход при попытке ее проанализировать и спроектировать, дает сбой.

25. Типичный случай такого сбоя описан в статье: "Система управления бизнес-процессами в госсекторе и местном самоуправлении - что помешало наладить взаимодействие"
https://docs.google.com/document/d/1tk2AZSrYrSRAwSSqVJICg42FHm6f13GMNu6dOeEEBYA/edit?usp=sharing
В статье рассказывается, как федерированная система управления жизненным циклом бездомных превратилась в трансдоменный объект и потеряла свою функциональность и пользу из-за того, что она больше не отражала жизненного цикла целевой системы. Фактически, она стала имплементировать интерфейсы между НКО, муниципальными органами, администрацией графства, правительством штата и федеральными органами исполнительной власти, а строить ее пытались методами проектирования автоматизированных систем.

26. Этот случай, на мой взгляд, показателен, потому что неудачные внедрения ERP или систем формальной отчетности при невыявленных или по факту несуществующих целевых систем приводят неудачным внедрениям. Ситуация осложняется еще и тем, что по факту многие части федерированных/распределенных автоматизированных систем по факту являются не системами, а ровно такими вот трансдоменными объектами. А мы пытаемся создавать их неподходящими методами. Трансдоменным объектом может стать модуль PLM или отдельные страницы Confluence, если команда находится в стадии формирования или слаживания, потому что никакого согласованного языка общения для них еще нет, процессы не отстроены, форма артефактов и рабочие процессы их создания не сформировались.

27. Причем надо разделять понятие "масштабов/scales" от понятия контекстов. Контексты включены друг в друга - контекст кооперации включает в себя организационные контексты, организационный контекст включает в себя операционные контексты, операционный контекст включает в себя системные контексты. В каждом случае у нас задаются границы систем, а сами системы входят друг в друга. И большие машиностроительные PLM авиастроительных или автомобилестроительных корпораций хорошо описывают такое множество предельно сложных контекстов с классами целевых систем с ограниченной вариативностью системных архитектур (продуктовых линеек самолетов, автомобилей, телефонов и радиоголов 5G).

28. Системная инженерия в таком случае лишается своей опоры и уступает место инженерии трансдоменных объектов, которая много где описана, см., например Boundary Objects and Beyond | The MIT Press Leigh Star et al. По этой теме есть множество статей, вбейте boundary objects engineering в плагине поиска Google Scholar и прочтите несколько аннотаций, вы поймете, о чем идет речь, см., например Communication through Boundary Objects in Distributed Agile Teams | Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems. У меня есть сильное подозрение, что в основе практик такой инженерии должна лежать дисциплина управляемой эпистемологии https://anticomplexity.org/category/upravlyaemaya-epistemologiya/

Использование трансдоменных объектов для имплементации орг. интерфейсов киберличностей и киберорганизаций
29. Miro, Фейсбук - это трансдоменные объекты, которые можно использовать для реализации эффективных орг. интерфейсов в хаотических (по Cynefin) средах управления. Трансдоменные объекты, далее ТДО в составе имплементаций орг. интерфейсов повышают информационную безопасность киберличностей и киберорганизаций, борются с проблемами перегрузки и делегирования Анны. Но за счет чего ТДО могут это делать и почему существующие ТДО, те же соцсети, в большинстве случаев либо нефункциональны либо деструктивны? Чтобы ответить на этот вопрос, необходимо дать контекст применения ТДО в хаотичных средах управления.

30. Одна из ключевых характеристик хаотичной среды управления - это отсутствие явных системных границ. Эта проблематика напоминает проблематику, существовавшую в военной науке, когда из-за возникновения масштабных партизанских и гибридных войн классические теории и объяснительные модели, основанные на наличии фронта и связанной с ним логистики, стали давать сбои. На смену им пришла теория маневренной войны. Киберличности, которые активно включают новые информационные технологии в свой контур, и киберорганизации, состоящие из этих киберличностей, размывают свои границы и, соответственно, классические теории безопасности, основанные на понятии периметра, также теряют свою предсказательную силу и начинают давать все больше сбоев. Точек потенциального доступа внутрь системного контура становится все больше, и протоколы взаимодействия с окружающей средой все слабее. Усиление периметра замедляет приспособляемость и время реакции. Ослабление периметра приводит к хрупкости системы предприятия. ТДО - возможный путь к антихрупкости. Как ТДО это делают?

31. Наличие границы, контура, периметра предприятия разделяет инсайдеров от аутсайдеров. То же различие проектных ролей (stakeholders) от команды основано ровно на том же.

 

Рисунок 8. Системная схема проекта в варианте СМ2019

32. И внешние проектные роли и команда - это некие субъекты, со своими целями, интересами, предпочтениями, практиками, методами описания. В чем отличие роли в команде от внешней проектной роли? Чаще всего методологи системной инженерии говорят про то, что команду объединяет коллаборация, совместная работа внутри жизненного цикла целевой системы. У команды есть разделяемый/общий синтаксис, язык общения (который зафиксирован в PLM, трекере и рабочем пространстве), есть метод и разделяемая/общая цель. Проектные роли же имеют свои языки общения, свои круги понятий, домены, свои методы, которые не согласованы с жизненным циклом проектируемой системы. Наличие целых уровней этой несогласованности целей, языков и методов и есть то, что исследователи в статье "Система управления бизнес-процессами в госсекторе и местном самоуправлении - что помешало наладить взаимодействие" назвали "масштабами". Польза ТДО в том, что они позволяют коммуницировать вне рамок общего синтаксиса, в пределах нескольких масштабов.

33. Для объяснения механизма работы ТДО необходимо ввести расширенное понятие ситуационной осведомленности (situational awareness). В классике понятие ситуационной осведомленности используется для объяснения того, как происходит координация в распределенных командах, когда ни один из членов команды или экипажа не может видеть всей ситуации. Допустим, при организации воздушных перевозок у пилотов есть свой набор информации, у диспетчеров воздушного движения свой, и для общего понимания того, что же на самом деле происходит, они должны определенным образом передавать нужную информацию в нужные моменты времени, поддерживать ситуационную осведомленность как понимание взаимного расположения физических объектов (самолетов, ВПП, земли, облаков и опасных погодных явлений) и прогнозных траекторий движения. Для целей бизнеса необходимо расширить толкование этого термина. Под ситуационной осведомленностью в бизнесе я дальше подразумеваю любой рациональный, разумный обмен относящейся к делу информацией как внутри команды так и команды с внешними проектными ролями. Неважно, касается ли это физических объектов или абстракций. Например, понимание динамики like-for-like конкретного магазина в сравнении с динамикой магазинов региона - это значимая информация, хотя и абстрактная. Обмен такой информацией между магазином и региональным менеджером поддерживает ситуационную осведомленность.

34. Итак, основная функция трансдоменных объектов - повышать ситуационную осведомленность команды или коллаборации команд. Если рассматривать страницу в рабочей области Confluence или страницы пользователей и ленту в социальной сети как некую имплементацию орг. интерфейса, как ТДО, то можно применить к ним методы проектирования интерфейсов. В частности, задать себе вопросы - а с какими системами в операционном окружении я сопрягаюсь через Фейсбук? Какие сервисы я от них получаю? По каким протоколам коммуникации работаю? Как обрабатываю ошибки и исключения? Как проверяю целостность сервиса? Как исключаю или минимизирую человеческий фактор в коммуникации? Как у меня организована аутентификация и авторизация, проверка на проникновение? Такой подход позволяет осмыслить применение социальных сетей в положительном смысле, а не идти на поводу геймификации, реципрокности лайков, не заниматься кармадрочеством, флеймом и срачами. Словом, самостоятельно распоряжаться своими ресурсами внимания, а не становиться субъектом департамента инжиниринга внимания Фейсбук Инк. Здесь я опять обращаюсь к изначальному посылу, что интерфейсы имеют двойственную природу - они не только физичны, но и должны осмысливаться в своих взаимосвязях.

35. Если рассмотреть карты Miro как ТДО, имплементирующий часть орг. интерфейса, то можно выделить еще одно свойство интерфейсов - коллокацию, совместное размещение. Zoom, Miro, почтовые клиенты, Zotero и Confluence - это ТДО, которые сводят всю коммуникацию в одном месте, обладают свойством коллокации. Любая система выполняет свою функцию, свое назначение четырьмя способами:
Inscriptions - встроенное в систему поведение
Prescriptions - предписываемое системой поведение
Restrictions - ограничения в поведении, накладываемые системой
Affordance - делегирование функций человека системе, что она позволяет сделать

по статье Берлинский ключ, или Как делать слова с помощью вещей. Бруно Латур.

36. Эффективный ТДО не имеет функции назначения, он текучий, меняющийся. Но он создает достаточно стабильный социологический фрейм (структуру ситуации, жесткий каркас структуры взаимодействия) ситуации общения, который позволяет поддерживать ситуационную осведомленность, прагматическое общение в хаотических средах. Поэтому теория фреймов (объяснение понятия и дисциплины см. Теория фреймов — Виктор Вахштайн) наряду с вычисляемой эпистемологией может составить ядро дисциплины инженерии ТДО. Эффективный ТДО должен по возможности исключить эскалацию ситуации общения на уровень руководства, то есть, с точки зрения интерфейсов, исключить вызов процедуры обработки исключений. Наиболее интересно направление исследований ТДО в интегрированных командах продуктов (IPT, integrated product teams), см. Integrating Program Management and Systems Engineering: Processes, Tools and Organizational Systems for Improving Performance Eric S. Rebentisch и в программах цифровой трансформации, см. Architectural Coordination of Enterprise Transformation, Proper et al.

Но это уже тема другой статьи, которая называется "Перфокарты в вашей голове".

Выводы и размышления

Современные процессные модели и методологии по большей части игнорируют понятие организационного интерфейса и разделения бизнес-процессов и практик. Практики орг. дизайна и информационной безопасности практически не учитывают появление киберличностей и киберорганизаций, и продолжают оперировать все менее функциональным понятийным аппаратом.
Трансдоменные объекты как часть имплементации организационных интерфейсов при соблюдении дисциплины их использования позволяют решить часть проблем организации коммуникации в хаотичных средах.
Основными дисциплинами использования ТДО могут быть социологическая теория фреймов и управляемая эпистемология.
Орг. дизайн, построенный на ТДО, может быть более устойчив, безопасен и более приемлем для работников.