Русский
Русский
English
Статистика
Реклама

Архитектура системы

Построение архитектуры социальной среды

20.07.2020 16:23:27 | Автор: admin

Вступление


Вы все система, которая так много знает. Вы решаете, что хорошо, а что плохо. Точно так же, вы решаете, что смешно, а что нет.
Джокер (Joker)

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

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

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

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

1. Суть проявления Среды


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

Для единого понимания темы, я подстроюсь под участников дискуссии и буду далее рассматривать явление Социального организма, как некую Сред.
Определимся с понятиями.

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

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

Резидент участник Среды.

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

2. Инструменты представления Среды


Всего-то и нужно, что замечать детали и как они складываются в систему. Когда ты поймёшь всю систему, ты сможешь экстраполировать будущее.
Чак Паланик (Уцелевший)

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

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

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

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

Важно, что один оригинал может иметь множество аналогов.

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

3. Взаимообусловленность Среды и Архитектора


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

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

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

По мере роста и развития Среды, часть функций архитектора может перейти другим резидентам (или группам), высвобождая Архитектора для генерации новых возможностей Среды. Причем функции роли Архитектора могут быть:
  1. делегированы архитектором (лучше разным резидентам), для сохранения единоуправления;
  2. потеряны подхвачены резидентами при попустительстве (бездействии) архитектора, чаще всего в усеченном (извращенном) варианте;
  3. аннексированы захвачены резидентами с отстранением архитектора от функции или роли целиком;

4. Взаимообусловленность Среды и Резидента


Приложи все усилия, чтобы общаться с теми, кто выше тебя. Это поднимет тебя, тогда как общение с людьми более низкого уровня вынудит тебя опуститься, ибо каково общество, в котором ты находишься, таков и ты сам.
Филип Дормер Стенхоп Честерфилд

Итак, мы установили, что Среда, является Эталонным аналогом Социальной реальности, организованная Архитектором в виде модели.

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

В связи с физиологическими особенностями человеческого восприятия мира, резидент может осознать модель (Эталонный аналог) лишь в определенном объеме, с определенными искажениями, интерпретируя его в сознании, в свой собственный Субъективный аналог.


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

Помимо степени осознания (понимания) модели резидентом, имеет место еще и степень ее принятия (разделения ценностей) в определенном объеме, обусловленным культуральным диапазоном его приемлемости. Часто, по уровню принятия, резиденты консолидируются в Среде, по группам единомышленников. Это перекликается со свойством системы Внутренняя неоднородность, сводящаяся к обособлению относительно однородных участков системы, проведению границ между ними.

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

5. Реакция Среды на внешние воздействия


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

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

В случае, когда этого не происходит, резиденты перестают принимать (разделять), предложенную Средой модель. Если же при этом у резидента еще и имеется оказия анализировать оригинал, то это будет способствовать созданию его собственного аналога и, быть может, он будет превосходить Эталонный

Подобное развитие может привести к нарушению такого свойства системы, как Ингерентность, согласованность, приспособленность к окружающей среде, совместимость с нею. В этом случае система перестает быть устойчивой и возникает необходимость в ее реорганизации. Например:
  1. Изменение эталонного аналога;
  2. Создание новой (конкурентной) среды, превосходящей старую;
  3. Отказ от поддержки старой среды;
  4. Сочетании вариантов.

6. Условия существования и развития Среды


Предоставленные сами себе, события имеют тенденцию развиваться
от плохого к худшему.
Артур Блох. Законы Мерфи

Бытует ошибочное на мой взгляд суждение, что Среда может сама себя развивать. Звучит как-то божественно, как бы среду развивает или бог или природа, кто как это называет.

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

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

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

7. Изолированность Среды


Любая система, зависящая от человеческой надежности, ненадежна.
Василий Головачев (Консервный нож)

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

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

Поэтому, изолированность Среды должна быть ровно такой, какой ее определил архитектор. При этом Среды могут быть, например:
  1. Открытыми полностью доступны для всех субъектов и других сред.
  2. Частично открытыми доступны для некоторых субъектов и сред, по взаимному контракту.
  3. Закрытыми открыты для ограниченного числа субъектов, являющихся резидентами среды.

Полностью закрытые, изолированные среды в крайнем воплощении это путь к сектам, диктатурам, небезопасным для остальных субъектов образованиям.

Полностью открытая среды в крайнем воплощении это путь к анархии и саморазрушению среды.

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

8. Среда, как единый организм


Как прекрасно почувствовать единство целого комплекса явлений, которые при непосредственном восприятии казались разрозненными.
Владимир Петрович Карцев (Приключения великих уравнений)

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

Как единое цело Среда, состоящая из субъектов (живых организмов) и сама проявляет некоторые свойства живых организмов. Я это подробно обсуждал в своей статье Социальный Организм как форма эффективного взаимодействия команды.

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

9. Цели заинтересованных лиц в использовании Среды


Как Вы считаете, человечество идёт вверх, возвышается, развивается, топчется на месте или деградирует?
Вы знаете, человечество никуда не идёт. Оно живёт.
Борис Борисович Гребенщиков

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

Сам факт существования Среды не может привлекать клиентов, если только исключительно в качестве любопытства. Людей привлекает возможность получения некоего профита: ожидание признания сообществом, получение дохода, завладение инструментом влияния на людей/сообщества и т.п. Только производные от них могут выступать драйверами привлечения в Среду.

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

Общие цели архитекторов:
  1. Создать модель (Среду) социального сообщества, для привлечения в нее перспективных резидентов;
  2. Обеспечить максимально комфортные условия для удержания резидентов с Среде;
  3. Делегировать резидентам Среды часть функций, по поддержанию ее функционирования и развития;
  4. Получить лояльных субъектов, для решения при помощи них своих основных бизнес-задач (Основная цель).

Цели резидента:
  1. Получить комфортную среду пребывания, для удовлетворения своих социальных потребностей (Основная цель).

10. Итоги


На основании этих основных постулатов (и возможно еще каких-то), можно выработать манифест организации социальной Среды. Например:
  • Для организации Социальной реальности, возникающей в Социальном сообществе, необходимо построить ее модель в виде некой Среды;
  • Среда должна быть представлена сообществу ее Архитектором и им(сообществом) одобрена;
  • Организацией Среды должны заниматься ее Архитекторы, либо резиденты, на которых Архитектором возложены соответствующие функции;
  • Каждый из резидентов имеет свое представление об организации Среды, отличающееся от представления, заложенного Архитектором;
  • Среда оказывает влияние на сознание резидента;
  • Резидент или группа резидентов, может оказывать влияние на Социальную реальность сообщества, заставляя тем самым изменяться Среду;
  • Любая Среда организует лишь часть функций Социальной реальности сообщества;
  • Среда должна обладать способностью противостоять внешним вызовам и соответственно реагировать на них;
  • Желательно, чтобы Среда обладала способностью развиваться;
  • Среда должна быть Изолирована от других Сред, ровно настолько, насколько этого требуют вопросы ее жизнедеятельности;

Добавьте свои варианты

Список литературы
[1] Ф.П. Тарасенко, ПРИКЛАДНОЙ СИСТЕМНЙ АНАЛИЗ, учебное пособие, Москва, 2010..
Подробнее..

Ежедневный стэндап для архитектора с оркестром

09.05.2021 00:17:30 | Автор: admin

Будни разработчика. Цели определены, направления выбраны, задачи разжеваны. Нужно просто писать код и жевать кашку. Что может скрасить серость и однообразность существования? Конечно же daily standup - шоу, в котором есть место для каждого! Ну вот эти вот неожиданные я посмотрел архитектуру и там ошибка или вот я добавил новый модуль, который нам может пригодиться в будущем ну и, конечно, я сделал всё проще и быстрей. Мы ведь именно ради этого делаем все церемонии груминга и планирования. Чтоб как бы подготовить почву и дать всем время посидеть молча и подготовить эти панчлайны на конец спринта. А самое обидное, что, потратив столько усилий, на сам стендап вы обычно не попадаете и панчи вам передаёт ваше начальство.

http://personeltest.ru/aways/www.flickr.com/photos/cosmic_flurk/5712236914@CCLhttps://www.flickr.com/photos/cosmic_flurk/5712236914@CCL

В чём интрига? В самой сцене. В самом начале дня у нас обычно дейли разработчиков. Там все делятся успехами и проблемами. Охотно так делятся. Долго и много. Как раковые клетки. Даже анализы можно делать. Чем больше тем на этом daily, тем больше опухоль в проекте. Потом придётся выжигать и резать. Но команд много, а архитектора мало. Поэтому его не зовут, если не уже дымится.

Дальше отсеиваются разработчики и в следующий тур идут только тимлиды. Они более практичны и рассказывают о своих успехах и как всё по плану, а проблемы выносят в оффлайн. Сухо так и без шуток. С dev. менеджером обычно всё позитивно, если менеджер сам не станет копать или не возникнет подозрение о том, что дедлайн слишком близко к носу. И так как начальник - человек занятой (его каждый раз кто-то занимает, но, как ни странно, каждый раз и отдаёт), команд много и проекты глобальные, то представитель от каждого сайта (ротация среди лидов) подключается к общему митингу, куда обычно и приглашают архитектора. Это самые бесполезные пол часа. Каждый уже пару раз рассказал свою историю и пережевал проблемы (а тут, видимо, как и с шутками: проблема, повторенная дважды, перестаёт быть проблемой). Вдобавок говорить то на английском надо, который для большинства неродной и куча акцентов Короче, каждый chosen one пытается сказать одно-два предложения, так чтоб не дай бог не задали вопросов. Как на приёме в налоговой.

Сетка игр в дейлиСетка игр в дейли

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

Поправка на ветер

Не все компании одинаковы. Как и фломастеры. Кое где есть много архитекторов и мало команд. Кое где нет трёх уровней сцены. Возможно, нет никаких трудностей с коммуникацией и прозрачностью implementation details, в которых дьявол. Так что пробуйте на вкус и цвет. Если нет проблем, то и жизнь хороша. Но как говорил агент Смит, в утопии можно потерять весь урожай. С местной командой всегда есть хороший контакт и неформальные связи. Разработчик может просто подойти и спросить. А вот если у вас куча удаленных единиц и они в какой-нибудь далёкой стране в другом часовом поясе, то с ними очень тяжело наладить прямой контакт. Особенно там, где очень уважают корпоративную иерархию и не умеют говорить нет. Не положено у них программистам подавать голос вне церемоний и без участия прямого начальника.

Из личного опыта: иногда доходит до абсурда. Был проект, где архитектором была девушка. А on-site менеджером в далёком стане усатый седой дядька с чалмой. Так вот пока кто-то из команды архитекторов-мужчин не посылал мейл: сделай как она сказала - раджа игнорировал все её заметки. Культур такой. В общем мудрый раджа оказался тем ещё мудрилой.

В чём же будни архитектора, помимо кофе и рисования? Ведь многие считают, что гнездо архитекторы вьют только из одноразовых стаканчиков в местах большого скопления whiteboard-ов. Конечно же в ловле личинок bug-ов! В первую очередь, конечно, интересуют ошибки проектирования. То есть свои же собственные промахи. До начала разработки архитектуру семь раз замеряли, но когда приходит время отрезать, выясняется, что попасть в метку тяжело, пила не та, то брус не тот. Все стройные теории начинают сползать с вакуумного глобуса. На этапе разработки первичной версии начинают выясняться все детали, которые попали в финальную версию контракта. Самые главные: дата и точный спектр функционала первого демо для клиента.

Первые конфликты требований не заставят себя ждать. Проблемы сами по себе очень пунктуальны никогда не запаздывают и даже стараются встретиться с вами пораньше. Мои наблюдения за природой событий подсказывают, что источником часто являются благие намерения и ограниченные знания (слабоумие и доброта). Чем меньше знаешь деталей, тем радужней и проще картинка. Поэтому клиенту обещают чуть больше и чуть раньше. Даже если не официально. Чтоб зарекомендовать себя, выиграть лишний бал для торгов на следующей фазе или обезопасить дедлайн/качество, насильно передвинув срок сдачи на пару недель раньше. Ну чтоб оставить чуток на допилинивание и стабилизацию. Спринт на закалку. Английское харденинг более уместно. Как только начинают двигать дедлайны взад-вперед, сразу же чувствуется харденинг. И если дёргать дальше, то проект может плохо кончить. Те же хорошие мысли подталкивают участников процесса добавить немного еще функционала из серии чтоб два раза не ходить. Такие вещи из бэклога, которые в том же куске что разрабатывается сейчас и весят мало. И как бы проверками их покроют всё равно и код уже открыт на нужном месте. Мелкие задания. Пару часов тут, пару часов там и вот уже появляются первые участки дороги в ад инженера.

7 фишек этому господину!7 фишек этому господину!

Ад у каждого свой. Мой похож на ежедневные диспуты с начальниками разных отделов, каждый из которых предлагает вместо твоей глупой инфраструктуры, давай сделаем анимированные кнопочки. Случалось же слышать: а юнит тесты точно нужно писать? А может можно как-то без них? или нам же сейчас не нужно это твоё скалкобилити, а красивый интерфейс это лицо продукта. Хорошее лицо тоже важно, но этот орган плохо поглощает кинетическую энергию и при встрече с бетонной реальностью лучше приземлиться на пятую точку. Особенную нишу занимают вот тут 20 дней на безопасность выделено, нужно сделать за 10, чтоб ещё пару фишек втиснуить из бессмертной серии а семь шапок можешь?. Мне всегда сложно объяснить кому-то почему же 2+2 = 4. На сложные вещи аргументация всегда находится, а как объяснить то, что ты считаешь базовым, да еще и когда экспериментально доказать за 5 минут не получится.

Флешбэнг

Вспоминается лектор в универе по линейной алгебре, который заставлял писать на экзамене типа один из результатов 2 + 2 будет 4. Точное определение операции сложения и поля чисел, на котором эта операция произведена указаны ниже. В противном случае сам давал произвольное определение так, чтоб 2+2 было 4+С или допустим (+4;-4) и не засчитывал ответ. Я тогда бесился, но похоже препод был настоящим инженером. Не даром его книги продают в переводах на несколько языков. Даром пишу тут я и пытаюсь передать его мысль: решений зачастую больше, чем одно и в разных условиях правильными могут считаться разные варианты.

Чтобы понизить градус ада приходиться заниматься презентациями, которые бы наглядно показали как у нас всё работает и почему. Хочется, конечно, Босха, но приходится сводить простые зарисовки со стрелочками. Анализировать бэклог, искать пересекающиеся требования и показывать, что кнопочки сейчас по затратам равны кнопочки завтра, а безопасность сейчас намного дешевле безопасность завтра. Строится цепочка требований ведущих или исходящих из кнопочки и такая же для требования безопасности. Так как бизнес-требования обычно не пересекаются, то цепочку таких требований легко двигать в плане вперёд и назад. А значит и цена будет неизменной. Инфраструктура же пронизывает все модули и цепочки, а значит если завтра будет в 10 раз больше модулей, то будет и в 10 раз больше интеграции/внедрения и проверок (важная статья расходов и времени). Кто бы мог подумать!? И обязательно гуглите что-то из серии цена ошибки безопасности в своём промышленном/деловом секторе. Для производства всегда хорошо работает пример Иранских центрифуг. В финтехе или ритейле примеров полным-полно. Хорошая страшилка лучше любых формул. Детей пугают сказкой про волка, а не расчётами семейного бюджета (хотя последнее может быть намного страшней).

инфраструктура шашлыкаинфраструктура шашлыкаНа моей памяти

Лет 10 назад из наших клиентов лидер в своём секторе в развитой европейской стране, спустился на пару пунктов в рейтинге и обороте после того, как его взломали. А другой наш клиент, бывший на третьем месте незамедлительно вложил тройной бюджет в безопасность и в том же году возглавил рейтинг. Хотя по размеру и размаху он раза был в 4 меньше. Сейчас проверил, они спустились на второе место, но с хорошим отрывом от их прежнего третьего.

Вот прошли вы семь кругов дневных совещаний и можно начинать работать. Ваша компания выиграла большой тендер в том числе и благодаря волшебной пыли, которой вы сдобрили своё видение решения в документах и диаграммах. Кто и как употребляет эту пыль не наша забота. Контракт подписан и пора её сдуть со всех чертежей. Под пылью много пустых мест, которые как раз сейчас время заполнять. Заполнять, конечно, можно с фантазией в начале всё легко исправить и цена ошибки минимальна. Поэтому я советую подключать к проектированию модулей инфраструктуры самих разработчиков. Если хорошему программеру выдать конечный результат в стиле сделай вот так, то он может и сделает, но осадочек то останется. Основные узлы строят специалисты и у них есть свое мнение, которое они хотят высказать не просто в стену, а чтоб их услышали. Это не плохо, но я люблю дело делать, а не говорить и слушать. Умел бы слушать и говорить играл бы в тиндеры, а не в тендеры. Да и мнение ключевых специалистов я уже выслушал, когда строил наброски и готовил решение. Теперь, когда всё утверждено и подписано, начинать с начало как минимум не практично.

Мой know-how в этом процессе направляемый мозговой штурм. У вас есть готовый вариант архитектуры модуля. В моём случае это значит, что определена модель (абстракции) и контракты (данные) и есть сопутствующая диаграмма взаимодействий или сущностей. Так вот эту диаграмму я начинаю строить с разработчиком, скармливая ему требования и проблемные аспекты так, чтоб он посмотрел в конце на моё решение и сказал классно мы с тобой придумали!. Ну ещё бы.

Работает это примерно так:

Нужен модуль, который получает пакет цифровых документов и мапит их в базу. Разработчик сразу предлагает какой-нибудь pub-sub, асинхронные (так почему-то 80% людей называют параллельные процессы) таски и пару микросервисов. Куда же без них.

первый предложенный вариантпервый предложенный вариант

Теперь надо подхватить его под руку и вести туда, куда хотите вы. Закидывается проблема и предлагается решение, которое у вас прописано в архитектуре. Как-то так: Хорошее решение, но если у нас будет асинхронный маппинг, то возникнут проблемы совместного доступа. А что, если вместо параллельности мы сделаем последовательность?.

второй предложенный вариантвторой предложенный вариантПро параллельность

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

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

конечнаяконечная

За шага 3-4 мы уже достигаем желаемого результата. В отличии от варианта, когда вы просто объясняете почему стоит сделать именно так, вы не лишаете человека самого важного поиска решения. Разработчик не стенографист и не стал экспертом потому, что просто быстро записывал за кем-то построчно. Если лишить его загадки, то работа может вызвать протест и кучу отрицательных эмоций. С другой стороны, он не знает всей картины. Ни того, что и как будут делать в других командах, ни того, что запланировано на полгода вперёд. В этом основная причина существования должности архитектора широкий и далекий взгляд на проект. Но ничего не получится, если ваша архитектура не обоснована требованиями. Нечем будет вести разработчика, да и незачем. В таком случае лучше честно партбилет на стол. У нас с этим строго. Это по утрам я Винни-Пух, а к концу дня я свинья с ружжом!

архитектор бьёт чучелом ружья вымышленного леопардаархитектор бьёт чучелом ружья вымышленного леопарда

И стрелять всегда есть в кого. Пока все усердно пишут код нужно следить, что б всё неусерднулось. Тут на помощь нам всякие индикаторы и статические анализаторы кода. Делать метрики для программистов удел менеджеров. Я лично озабочен метриками кода. Индикаторы здоровья проекта:

  • Отсутствие взрывного роста строк кода после первых шагов. Как только мы закончили строить базу и перешли непосредственно к бизнесу, то коммиты должны быть частыми и небольшими. Меньше кода практически всегда, лучше код. Поэтому если кто, то навалил кучу, то скорее всего там проблема с заданием и расхождением с линией архитектуры.

  • Длинные функции и классы не плохой индикатор поспешной работы и костылей. На начальном этапе такого быть не должно.

  • Сложность кода можно отследить по количеству юнит тестов при высоком покрытые. Много тестов значит много веток, а значит опять что-то попахивает.

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

  • Много статики (классов, методов, полей), обычно, проявления антипаттернов.

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

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

Для подготовки к следующему этапу необходимо выстроить хороший механизм логирования. Желательно на два уровня один с понятной историей для бизнеса, а второй для технического анализа, что же всё-таки навернулось. Когда со стадии демо мы шагнём, пусть и в ограниченный, но production, то там будут первые кострища и охота на ведьм. Наблюдать в полнолуние как кто-то седеющими руками набирает код прям в проде плохая примета. По возможности старайтесь избегать этого. Так что одним стримом пишем: пользователь ****341 запросил функцию Поиск Заказа с аргументом 3480-4341-1334. Результат: не найдено. На этот лог сядет саппорт, когда процесс встанет. А второй стрим со стеком, сервисами и всеми деталями (опять-таки, кроме тех, что нужно замазать ради безопасности или для сохранения личных и коммерческих секретов). Тут уже пойдут разработчики, когда процесс ляжет. Логи делать необходимо с самого начала. Они всегда нужны вчера, когда всё случилось, а вот завтра от них будет мало толку. Клиент как-то не любит слышать: У вас тут вчера производство встало, а мы не знаем почему. Но когда встанет в следующий раз у нас будет больше данных для анализа!. Хотя в некоторых компаниях лишь под угрозой штрафов начинают понимать, что стоило вложиться сразу в аудит и мониторинг да начинают чесать головы (те в которые едят и те на которых сидят).

Мысль вслух

Есть разные архитекторы. Сейчас самый хайповый архитектор решений. А нужен то архитектор проблем. Тот, кто предскажет нестыковки и видит конфликты. Опытный разработчик справиться с решением любой правильно поставленной задачей и сам. Архитектор необходим чтобы сделать задачу правильной и полной (не бодипозитивной, а с жирными мазками в местах болевых точек и сочным описанием того, что случиться, если на точку нажмут). Мне не важно пустой ли на половину стакан или полный. Мне важно определить, что значит половина и, что стакан будет в том месте и времени, когда начнут лить. И стоит уточнить, что лить будут не серную кислоту в бумажный стаканчик.

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


Подробнее..

Выбор оборудования для системы контроля доступа

19.06.2020 12:20:11 | Автор: admin
При построении системы контроля доступа определяющими параметрами являются быстродействие, надежность, удобство использования и соответствие поставленным задачам.



Архитектура СКУД


В современных СКУД связь между контроллерами, рабочими местами пользователей и сервером системы осуществляется по сети Ethernet. Интерфейс Ethernet обеспечивает высокую надежность работы системы за счет применения типовых IT- решений и работы всех устройств системы в едином адресном пространстве по единому протоколу. Ethernet также дает возможность использования технологии PoE (Power over Ethernet) привлекательного альтернативного способа электропитания сетевых устройств, существенно облегчающего монтаж оборудования СКУД.

Все контроллеры и ПК системы работают в единой информационной среде с единой базой данных, установленной на сервере системы. При этом наличие постоянной связи контроллеров с БД не требуется.

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

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

Для обеспечения автономной работы контроллера важной характеристикой является объем памяти. Например, современные контроллеры могут хранить в памяти данные о 150 000 событий и 50 000 пользователей.

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

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

Важным параметром при выборе контроллеров для СКУД является количество управляемых исполнительных устройств. Универсальные контроллеры в зависимости от настроек могут управлять турникетами, шлагбаумами или замками. Применение контроллеров второго уровня позволяет организо-вать на базе одного сетевого контроллера, например, доступ через турникет и в 10 внутрен-них помещений или через два турникета и в 8 внутренних помещений, существенно снизив затраты на внедрение СКУД.

При выборе контроллеров для СКУД стоит обратить внимание на наличие у них дополнительных входов/выходов для подключения дополнительного оборудования: видеокамер, датчиков, устройств сигнализации. Вход Fire Alarm позволяет подключить устройства пожарной сигнализации и настроить разблокировку турникетов при получении тревожного сигнала от устройств ОПС. При подключении камеры к выходу контроллера можно задать алгоритм, при котором камера начинает вести запись при получении сигнала о тревожном событии. К входу контроллера можно подключить датчики затопления: при достижении определенного уровня воды по сигналу от датчиков турникеты разблокируются для эвакуации. Дополнительные входы и выходы также позволяют подключать внешние верифицирующие устройства, например, пирометры, алкотестеры, весы.



Контроллер как сервер


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

Контроллеры нового поколения позволили встроить программное обеспечение, что дало возможность использовать контроллер как сервер. Такая архитектура упрощает внедрение системы и снижает ее стоимость. Например, система PERCo-Web, построенная на без такого контроллера, может обработать данные 500 сотрудников и 500 посетителей и иметь в соста-ве до 10 контроллеров. Контроллер подключается к сети по интерфейсу Ethernet. Для кон-троля доступа в компании численностью до 100 сотрудников будет достаточно бесплатной версии ПО.
Развитие интернет-технологий и пропускной способности каналов позволяет говорить о том, что Web-технологии в скором времени заменят традиционный подход к разработке не только программного обеспечения СКУД, но и вообще любых систем. По мере появления все более мощных контроллеров все возможности ПО систем контроля доступа можно будет реализовать в них самих, без установки сервера системы на компьютер.

Web-интерфейс контроллеров


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

Возможности интеграции


Получение SDK контроллера позволяет осуществлять интеграцию с различными системами: например, системами платного доступа или ERP-системами. Открытый протокол контрол-лера позволяет организовывать на его базе контроль доступа в фитнес-центрах, музеях, теат-рах, парках развлечений, на парковках и многих других объектах.

Выбор способов идентификации


При выборе оборудования для системы контроля доступа необходимо определить, какие способы идентификации будут использоваться на объекте: карты доступа форматов EMM/HID или MIFARE с защитой от копирования, мобильный доступ, доступ по штрих-коду, отпечаткам пальцев, распознаванию лиц. Характеристики контроллеров и считывателей должны позволить реализовать выбранный способ идентификации.

Для связи контроллера и считывающих устройств применяются интерфейсы Wiegand, RS-485 и USB. Wiegand применяется в СКУД для чтения магнитных карт и RFID-идентификаторов. Среди достоинств интерфейса: простота, распространенность, дальность действия до 150 метров, совместимость оборудования различных производителей. Среди недостатков уязвимость для взлома за счет отсутствия двухсторонней аутентификации и шифрования данных, отсутствие контроля целостности передаваемых данных и линии между контроллером и считывателем.

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

Для использования сразу нескольких способов идентификации, например, доступа по картам EMM/HID и MIFARE с защитой от копирования, а также мобильного доступа можно выбрать мультиформатные считыватели. При выборе считывателя важно обращать внимание на такие характеристики, как рабочий диапазон температур (при использовании на открытом воздухе), степень защиты IP и вандалозащищенность.

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

Архитектура системы и Бизнес-архитектура

07.08.2020 02:09:25 | Автор: admin


После достаточно продолжительного созерцания того, как различные специалисты объясняют (устанавливают) своё понимание архитектуры, я решил, что нужно им, всё-таки, помочь :)
Критиковать не стал, но предложить есть что.

Архитектура и строительные конструкции


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

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

Инженерная часть проекта состоит из детальных схем:
  • Системы водоснабжения и канализации схема разводки водоснабжения, аксонометрическая схема водоснабжения, схема разводки канализации.
  • Отопления и вентиляции схема разводки отопления, схема разводки вентиляции, обвязка котла (при его наличии).
  • Электроснабжения разводка освещения, разводка силовых сетей, схема ВРУ, система по заземлению.

Архитектор занимается только архитектурными разделом, а конструкционным разделом и инженерной частью занимаются соответствующие инженеры.

место для размышлений

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


Архитектура системы


Теперь рассмотрим определение, которые ближе к IT. За основу возьму выдержки из статьи.
Архитектура фундаментальные понятия или свойства системы в ее окружении, воплощенные в ее элементах, отношениях и принципах ее проектирования и эволюции. (Из: ISO/IEC/IEEE 42010:2011)

Такие и подобные определения обычно использует в крупных архитектурных фреймворках, наподобие TOGAF и SAFe. Эти фреймворки достаточны тяжелы и состоят из небольшого набора практик, которые систематизированы и разбавлены множеством различных методик и приемов. И это всё-всё преподносится как лучшие практики, хотя никто не тестировал и не применяет их целиком в таком виде целиком.
Архитектура это проектные решения, которые тяжело изменить. (Мартин Фаулер)

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

Можно утверждать, что таким образом раскрывается значение слова фундаментальные в определении Архитектуры по ISO, это то что тяжело изменить.
Суть создания архитектуры структурирование. Структурирование может означать превращение формы в функцию, извлечение порядка из хаоса, или преобразование частично сформированных идей клиента в пригодную для работы концептуальную модель (Эберхард Рехтин).

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

Проблема


Проблема у указанных выше определений, хотя они и полезные, всё же есть, они оторваны от идеи, заложенной в систему. Выделять архитектуру по критерию тяжело изменить довольно странно.
Также определение через составляющие в данном случае не передает необходимый смысл.

место для размышлений

Большая часть системных архитекторов вышло из программистов, они все технократы. Это всё придумали они. :)
При работе с архитектурой лучше сфокусироваться на назначение Системы.

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

Это проектное решение, которое колеса, двигатель, корпус и рулевое управление организует в автомобиль.
Другими словами, Архитектура это проектное решение, которое дает эффект эмерджентности. Эмерджентность появление у системы свойств, не присущих её элементам в отдельности; несводимость свойств системы к сумме свойств её компонентов.
Важно не переборщить с уровнем абстракции. Также позже, может возник возникнуть вопрос, что такое хорошая архитектура? Архитектура должная обеспечивать реализацию трех основные атрибутов качества системы: надежность, эффективность, гибкость. Есть и другие, например, масштабируемость, тестируемость, ремонтопригодность и др., но они не всегда так важны.

Бизнес-архитектура


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

Но всё же, этого будет недостаточно, чтобы это понять нужно рассмотреть базовые концепции и принципы.

Концепция Три вида деятельности


Существуют три вида деятельности:
  • Управляющая деятельность, которая управляют функционированием системы. Примером управляющего процесса может служить Корпоративное управление и Стратегический менеджмент.
  • Основная (Операционная) деятельность, которая является основой бизнеса компании и создают основной поток доходов. Примерами операционных бизнес-процессов являются Снабжение, Производство, Маркетинг, Продажи.
  • Поддерживающие деятельность, которая обслуживают основной бизнес. Например, Бухгалтерский учет, Подбор персонала, Техническая поддержка, административно-хозяйственный отдел.

Поддерживаю деятельности часто отдают на outsource. Не всегда деятельности, которые указанные в примере выше как основные являются основными, потому что их тоже можно на outsource. Управляющая деятельность всегда есть, теоретически можно всё зааутосорсить кроме управления, и сделать компанию виртуальной.

Outsource управления:
Если хотите потерять управление? Отдайте его на outsource. :)


Концепция Циклы Деминга


Итак, мы, как архитекторы, разделили деятельность компании на три части. Теперь нужно понять, а как же это все вместе работает. Для этого нам потребуется еще одна старая, но по-прежнему актуальная концепция цикл Деминга, он же PDCA:
  • Планирование
  • Действие
  • Проверка
  • Корректировка

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

Если с этапом Действие и Проверка всё, кажется, понятно, то Планирование и Корректировку нужно посмотреть поближе.

Концепция Принятия решения


Тут нам понадобится третья концепция Принятие решения. Это универсальный подход для решения управленческих задач и проектного управления.
  • Уяснение задачи
  • Оценка ситуация
  • Разработка вариантов решения
  • Выбор решения

Важно понимать все шаги этой последовательности и что нужно для ее выполнения. Этот подход применяется при планировании и в зависимости от ситуации при корректировке.
Давайте сопоставим эту концепцию с нашими проектами:
  • Как выполняется уяснение задачи?
  • Как выполняется оценка ситуации?

А теперь поднимемся на уровень руководства.
  • Как руководство обеспечивается информацией в части корректировки и оценки ситуации, то есть, где отчеты по нашему проекту, чтобы они поняли хорошо всё или плохо?


Принцип Целевое назначение должно определять архитектуру


Тут важно напомнить определение архитектуры:

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

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

Принцип Архитектура должна соответствовать руководству


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

место для размышлений

Определение Бизнес-архитектуры


Что касается специализированного определения, то с учетом того, что бизнес и IT идут сейчас плечом к плечу, по моему мнению, лучше Бизнес-архитектуру воспринимать как набор решений на верхнем уровне абстракций Архитектуры предприятия.
Из существующих определений мне нравится, которое дала группа Architecture Board Special Interest Group (BASIG) (Специальный совет по архитектуре OMG)
A Blueprint Of The Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.

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


Архитектор


Если дать нормальное понятие архитектуры, то роль архитектура становится предельно понятной.
Задача сапожника изготавливать и ремонтировать обувь.
Задача архитектора создавать и управлять архитектурой. Он должен создать решение, которое соберет все другие решения в систему.
Какими компетенциями он должен обладать?
Архитектор должен знать архитектурные принципы на своем уровне бизнеса или системы, это его hardskills.
Также архитектор должен быть драйвером, описать архитектуру это половина дела, а вот убедить людей воплотить и постоянно поддерживать её это вторая, не меньшая задача.
Для этого у архитектора должны быть хорошо прокачены softskills.
Есть еще одна характеристика, которая отличает архитектора от аналитика и программиста, он должен владеть оперативным искусством.

место для размышлений

Ссылки


  1. http://www.ovikv.ru/строительный_проект.htm
  2. pubs.opengroup.org/architecture/togaf9-doc/arch/toc.html
  3. pubs.opengroup.org/architecture/togaf9-doc/arch/chap20.html
  4. docs.microsoft.com/ru-ru/dotnet/architecture/modern-web-apps-azure/architectural-principles
  5. www.omg.org/bawg/business_architecture_overview.htm
Подробнее..

Recovery mode Страшные сказки на ночь, о PCI шине

30.10.2020 18:08:58 | Автор: admin
Всеобщая эйфория от появления на рынке новых процессоров, не дает достаточно времени кинуть взгляд, а что же там у них под капотом. Те же их стороны, которыми обычно восхищаются кликатели и кнопкодавы, вовсе не отражают реальное положение дел на железном фронте.
А тучи, тем временем, сгущались. Да, процессоры стали быстрее. Да, действительно, там стало больше ядер. И последнее, как раз, является серьезной архитектурной проблемой. По крайней мере, для наметившегося лидера гонки.
Кто сейчас помнит такой архаизм как Архитектура? Мало кто. Слово в станкостроении стало в IT, практически ругательным. А ведь когда-то, в былые времена, книга PCI System Archetecture и прочие, зачитывалась до дыр, на экране. И что же там такого страшного, в этом осколке прошлого, накарябано о PCI, что может нас ввести в глубокую задумчивость, полную вселенской грусти?
Страшная цифра 256. Хотя, на первый взгляд, и не очень страшная. Да, именно столько, и есть максимальный предел присутствия независимых PCI устройств, на PCI шине. Цифра кажется на самом деле заоблачной.
Ну кому, в здравом уме и твердой памяти, прийдет в голову иметь в компьютере больше 5-10 реальных, т.е. физических устройств? Именно исходя из этих логичных предпосылок, недавний лидер процессорной гонки, вводил ограничивающие настройки в свой чипсет, дающие возможность принудительно ограничивать волшебную цифру до 128, 64, и не поверите 32(!) PCI шин. И это была не просто блажь, т.к. давало серьезную возможность экономить
системнй кусок (первые 4Gb) памяти, до сих пор наделенный "волшебными свойствами" в отношении ОС. В том то и дело, что физических устройств было до недаванего времени не очень много.
Но, время не стоит на месте, и вот я держу в руках очередное 64 ядерное чудо враждебной техники, Rome от AMD.
И что же он хочет, нет ТРЕБУЕТ, для своего минимального функционирования? Всего то малость откусить для своих 64 ядер пространство в 80 PCI шин. Браво. Но, ведь у нас есть еще 2/3 пространства? У кого то есть, а у кого-то и нет.
Первый раз, на не бездонность PCI шины, я обратил внимание настраивая PCI расширитель, так уж получилось, что на нем висело, за гроздью из P2P мостов Pericom, 119 PCI устройств требовавших подобное же количество индивидуальных PCI шин. И это только за единственным х8 PCI расширителем. А таких х8 портов, там было 8. Вот тут, как бы невзначай, и всплывает "волшебность" первых 4Gb системной памяти, когда львиная доля из тех 119 PCI устройств, требует для своей инициализации во время обнаружения БИОСом скромные 32-64 Мб на каждого.
Хорошо что Интел не так мощно выгрызет PCI пространство. При необходимости, но повесить второю гроздь еще оставалось возможным.
А вот с Rome и единственное такое расширение лишает нас надежды хоть на какое то будущее столь увесистой грозди, в этой АМД системе. Нет, конечно, клиенту можно предложить перейти на суперкомпьютерную архитектуру, та которая будет под заказ и выльется в 10 раз дороже. Но и выше продложенная конфигурация, как вы успели заметить не для каждого их нас. И так же разрабатывается индивидуально под хотелки клиетна. Но архитектурная граница хотелок уже ощутимо близка. Не хочется в каждую вышку мобильной связи лепить суперкомьютор, исключительно из-за тридцатилетней ограниченности PCI шины. Что самое интересное, но переход на ARM совершенно не выход, поскольку на нем мы видим все тот же PCI, и все те же 30 летние ограничения.
Увы, ситуация в деталях повторяет тенденцию с памятью, стало мало? Пихай-суй больше! PCI пространство есть? Что его жалеть, от него не убудет. Увы, уже убудет. Уже, не то что в четверо или вдвое не обрежешь, чем баловался Интел. Уже и в полном обьеме, для серьезных игроков на грани. И применение транспорентных P2P мостов, увы только паллиатив, в сложившейся ситуации.

Только и остается что беречь каждый байт адрес шины. Или мечтать о том что крупные игроки созреют для создания IP6 адресов SuperPCIExpress.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru