Почему возник вопрос: «инженеры ли мы»?

Не только потому, что этот вопрос часто звучит в сообществах. Ещё и потому, что сложные промышленные системы должны создавать профессионалы, инженеры. Иначе ничего не изменится.

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

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

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

Надеюсь, что найду время и соберу результаты своих исследований в посты, на полноценную статью времени точно не хватит.

Пока скажу только одно: с моей точки зрения, профессионал — это искусный мастер. То есть человек, который очень хорошо, профессионально умеет что-то делать.

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

А что же дальше?

Мы рассмотрим важнейшие свойства систем: иерархичность и самоорганизацию. Затем разберёмся со стейкхолдерами.

И после этого приступим к моей самой любимой теме: моделированию и моделям.

Почему порядок именно такой?

На мой взгляд, без моделирования к проектированию и конструированию лучше вообще не приступать.

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

Также нужно четко понимать, кто и для кого строит модели, поэтому важно разбираться в стейкхолдерах.

И, конечно, мы всегда помним, что строим системы в интересах стейкхолдеров, которые проявляются на разных уровнях.

Изучение иерархичности начнем с ТРИЗ, а именно со знаменитого, даже гениального, системного оператора Альтшулера. Его также называют 9-ти экранкой или многоэкранной схемой мышления.

Перед этим приведу цитату из статьи "РАЗВИТИЕ СИСТЕМНОГО МЫШЛЕНИЯ – КОНЕЧНАЯ ЦЕЛЬ ОБУЧЕНИЯ АРИЗу (Альтшуллер Г. С., 1975, Баку).

«Качественное отличие талантливого изобретателя и состоит в умении видеть не только данную в задаче систему, но и надсистему и подсистемы:»

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

«Чтобы лучше разглядеть гору, необходимо спуститься в долину. Чтобы рассмотреть долину, нужно подняться на гору». Принято считать, что это высказывание принадлежит Никколо Макиавелли

Кажется, всё очевидно и просто. Однако, мы часто замечаем, что при проектировании систем архитекторы и те, кто исполняет эту роль, не видят надсистемы и не учитывают интересы ключевых стейкхолдеров, как и не умеют выполнять декомпозицию на подсистемы.

Альтшуллер впервые предложил системный оператор в книге «Творчество как точная наука», 1979 г. Приведу несколько цитат и иллюстраций из этой книги:

«Технические системы существуют не сами по себе. Каждая из них входит в надсистему, являясь одной из ее частей и взаимодействуя с другими ее частями; но и сами системы тоже состоят из взаимодействующих частей - подсистем.

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

«Иными словами, когда речь идет о дереве (системе), надо видеть лес (надсистему) и отдельные части дерева (корни, ствол, ветки, листья - подсистемы).

Впрочем, этого мало - на каждом этапе необходимо видеть линию развития: прошлое, настоящее и будущее (рис. 8).»

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

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

@IndustrialSoftwareArchitecture

Часто в одном предложении или высказывании можно увидеть как высокоуровневые абстракции, так и детали реализации на конкретном языке программирования. Такое смешение уровней абстракции значительно усложняет восприятие информации и затрудняет коммуникацию. Это довольно распространённая ошибка. И это свидетельствует о наличии "каши в голове».

Важно отметить, что на самом деле системы, надсистемы и подсистемы — это всё системы. То, чем является система в данный конкретный момент — надсистемой, подсистемой или собственно системой — зависит от уровня рассмотрения и от того, какая именно система интересует нас в данный момент. Чуть позже мы вернёмся к этому вопросу и добавим немного деталей.

В разных источниках системный оператор изображается по-разному. Мне нравится вариант, который представлен в книге Владимира Петрова «Талантливое мышление. ТРИЗ». Он привлекателен тем, что в этом варианте удобно отображать особенности программных систем. И на следующем шаге мы это увидим.

А сейчас приведу цитату из этой книги и ещё немного порассуждаю о системном операторе.

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

#ИМХО #оффтоп

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

Помимо преимуществ, независимость и автономность может вызывать странные эффекты, истреблять холизм и разрушать целостность систем.

Что это значит на практике? На практике это означает невозможность успешной реализации крупных программ и масштабных кросс-продуктовых инициатив.

В посте выше я употребил термин «холизм». Давайте вспомним, что он означает.

В академических статьях и словарях я не нашёл для себя определения, простого и удобного для объяснения, поэтому скомпилировал определение из разных источников.

"ХОЛИЗМ (греч. holos - целый) - понятие, связанное с разработкой в 20 в. системной методологии и системной парадигмы в познании. ...
Холистическая позиция заключается в приоритетном рассмотрении целого с точки зрения возникающих при взаимодействии элементов в системе новых качеств или целостных свойств, отсутствующих у составляющих систему ингредиентов." (Новейший философский словарь, А. А. Грицанов, 1999 г.)

В википедии даётся уточнение возникновения этого понятия:
"В узком смысле под холизмом понимают «философию целостности», разработанную южноафриканским философом и политическим деятелем Я. Смэтсом, который ввёл в философскую речь термин «холизм» в 1926 году, опираясь на идею, которая восходит к «Метафизике» Аристотеля, что «целое есть нечто помимо частей»".

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

Сейчас в разных областях деятельности развивается междисциплинарность. Междисциплинарность предполагает использование холистического подхода.

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

В сложных, комплексных программных системах мы больше не разделяем операционные/транзакционные и аналитические решения; они представляют собой две взаимосвязанные части системы.

Мы рассматриваем бизнес-архитектуру, архитектуру приложений, архитектуру данных и другие «архитектуры» как разные части единой архитектуры системы.