Примерно все так и отвечают. Но, можно ответить более строго. На предприятиях есть следующие типы деятельности: основная, обеспечивающая и управленческая. Результатом основной деятельности является продукция предприятия, результатом обеспечивающей деятельности - ресурсы для основной деятельности. Результатами управленческой деятельности являются все планы деятельности. Пример. Для того, чтобы сотрудник начал деятельность, руководитель должен ему выдать задачу. Задача - это объект, характеристики которого заполняются в рамках его действия (управленческой деятельности) - на выходе этого действия объект Задача, на который можно посмотреть через паспорт (карточку). Задача - это план деятельности.

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

У нас здесь пару дней назад как раз была содержательная дискуссия про цели vs. задачи.

#Спросить(↓)

Кстати, тезис "EA умер" - это не про "старый и плохой, давайте хоронить" - а про то, что ворочать в 2019 году арх.паттерном "EA" - это не жить в настоящем.

Да. Целостность - это ключевая характеристика. Но я бы ее применил не к архитектуре, а к модели предприятия, построенной на этой архитектуре. Т.к. целостность понимаю я такое представление, которое дает возможность представлять себе по видимой части системы ее любую невидимую часть. Пример из жизни - мы смотрим на автомобиль с одной стороны и не видим другую. Однако мы почти на 100% уверены, что другая сторона такая же. Пример для нашей модели предприятия. Мы смотрим на предприятия с "высоты птичьего полета", видим предприятие в виде черного прямоугольника, который связан по входам и выходам с поставщиками и потребителями (другими черными прямоугольниками). Но мы уверены, что этот черный прямоугольник содержит вложенные прямоугольники - функциональные подразделения, те содержат вложенные прямоугольники - задачи, а последние - действия.

А интересно было бы вам попробовать модель строить не на "всего слона за год" - а "на каждую часть тела - по 4 часа" ?

Я из "секты свидетелей Нонака и Такеучи" (которые, кстати, SCRUM придумали), мне "Компания-создатель знания" ближе, чем "Если мы хотим качественно управлять деятельностью - мы должны управлять действиями всех участников деятельности".

Мы так и строим конкретные решения: Система управления проектами, система управления вагоноперевозками, система управления спортивными соревнованиями, система управления закупками и т.д.

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

Прочтение TOGAF вызывает у меня вопросы:
- неужели можно заранее знать как сделать все правильно во всех аспектах и нарисовать это в диаграммах?
- выглядит как модель execute & control, которая не работает или работает очень плохо в больших структурах

O-AAF выглядит как смещение акцента в сторону guidance, то есть формирования практик со смещением принятия решений на места, согласно принятым стандартам в организации

Архитектура наиболее востребована в больших организациях. В этом и трагедия TOGAF. Мне гораздо больше в этом отношении нравится, как управляет развитием например ANCI через например ISO.

»  со смещением принятия решений на места, согласно принятым стандартам в организации
Да, именно

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

У меня к Кафка один вопрос. Называется он " хороший-плохой-хороший". Вы его как решаете?

А еще рассказал тут про нее эксплуатнам, так они просто засмеялись когда я сказал, что persist ack в реплики не подразумевает fsync.  сейчас меня больше прельщает apache pulsar.

Но pulsar пока не трогал, только читал

А в Кафке вообще не надо думать про fsync, там надёжность через реплики. Fsync если ждать, то будет как с любой БД - медленно. Смысл Кафки в отсутствии fsync.

Про 'хороший-плохой-хороший' не понял...

Ну вы считали три сообщения из партиции пачкой a, b, c. A обработали, b нет, c обработали. Что делать с офсетом?

Раз порядок не важен, то b вернуть в очередь, сдвинуть оффсет на 3

А если важен, то c нельзя обработать.

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