Pull to refresh

Comments 87

Да уж, сколько ни читал про все эти архитектуры предприятия и бизнес-процессы — все равно содержательная часть сводилась к обычным диаграммам и блок-схемам.
Исходя из концепции, что экономика – это ремесло, подчиняющееся четким требованиям по достижению результата как любая техническая (кибернетическая) система, можно сделать следующее определение архитектуры предприятия:

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

На практике существует всего две модели управления:
— иерархическая, описываемая структурой данных «дерево»
— сетевая, описываемая структурой данных «граф»

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

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

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

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

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

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

Что же касается бизнеса различных консультантов, то здесь остается только привести слова классика – «ах, обмануть меня не трудно, я сам обманываться рад». Для большинства начальников мыслительная деятельность достаточно утомительна, поэтому все они хотят «большую красную кнопку», которая бы решала за них возникающие на предприятии проблемы. Тем более, что за эту «большую красную кнопку» нужно платить не из своего кармана, а кармана собственника бизнеса. На этом и делают свой немаленький гешефт различные консультанты.
Вы рассматриваете лишь часть ЕА, назовем ее архитектура системы управления (СУ) предприятием. Можно назвать — общая модель управления предприятием (чтобы не путать с частной, с конкретной).

Есть много разных подходов, указав на «две модели управления» иерархическая и сетевая — Вы погорячились.
Одно из направлений — «50 оттенков управления компанией» (50 оттенков бирюзы), это где рассказывают: как хорошо компании быть бирюзовой (красная, янтарная, оранжевая, зеленая и бирюзовая).
www.mann-ivanov-ferber.ru/teal-organization
habrahabr.ru/post/323532

Понятно, что 5 — это только основные цвета управления, а в реальности спектр больше: условно 50 и не цветного, а скорее серого.

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

Есть другие направления описания модели управления компании, например, дивизионная, матричная, проектная (нигде не видел).

У Вас в «иерархической» — смешение: из одной «оперы» — это дивизионная, из «другой» (50 оттенков) — это тоталитарное управление. Однако четкая иерархия не обязательно основана на тоталитаризме — деспотизме: «я – начальник, ты – дурак».

Да, все это архитектурные особенности предприятия, точнее: архитектуры системы управления предприятием. И эти суб-архитектуры также напрямую определяют (влияют на) общую архитектуру. С этим согласен.

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

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

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

Относительно цветов и оттенков следует сказать, что автоматизировать можно только количественные параметры. Цветовая же схема не подлежит автоматизации, пока не будет детализирована до (кибернетических) процессов, алгоритмов и структур данных.

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

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

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

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

самого понятия предприятия, то для меня это и есть управляющая надстройка

Почему только «управляющая надстройка»? А все остальное?

Кроме того, у Вас так часто встречается «управление процессами», то уже действительно непонятно про какой раздел алхимии идет речь: то ли про «ЕА», то ли уже о «ВРМ». См. п. 2.2 Laws of #BPM (Business Process Management)

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

Наиболее значимые результаты своего опыта начал выкладывать на сайт www.leossnet.ru.

Что же касается домохозяйств, то можно привести следующие примеры для обеих моделей:

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

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

Приведенные модели являются частными случаями и полностью определяются личностными качествами супругов.
Мне показалось, что в Вашем подходе слишком большое внимание уделено «семейности». Домохозяйство — это скорее экономическая сущность. Воспитание детей, семейные отношения и т.п. — это не главная атрибутика «household architecture» (НА).

Кроме того, ЕА и НA — это, прежде всего, все-таки схемы (реже таблицы).
Какую конкретную ссылку на указанном Вами ресурсе можно считать наиболее близкую по теме обсуждения?
Из концептуальных вещей следует смотреть страницу, содержащую ссылки на внешние ресурсы:
https://www.leossnet.ru/?page_id=67

В контексте статьи ключевым ресурсом является ссылка на статью Олега Кольцова. Процессный подход с точки зрения кибернетики:
http://process.mirtesen.ru/blog/43516691271/Protsessnyiy-podhod-s-tochki-zreniya-kibernetiki

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

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

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

Чарльз Т. Хорнгрен, Джордж Фостер, Шрикант Датар. Управленческий учет.
https://www.litres.ru/dzh-foster/upravlencheskiy-uchet-17181345/

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

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

К параграфу №3 статьи: Предлагаю поговорить о «выходах» домохозяйства, точнее «продуктовых» выходах. Какой по Вашему «Каталог продуктов и услуг» домохозяйства. В терминах «продуктов и услуг».

Например, продукт домохозяйства «второй ребенок» оценивается заказчиком (государством) в 250 тыс., другие тарифы на «продукты НА» приведены
posobie-expert.ru/regiony/detskie-posobiya-v-moskve

Какие иные продукты, кроме категории «детские» попадут в Каталог продуктов и услуг НА?
Вообще есть сомнения, по поводу «самой значимой целевой функции» — воспроизводство. Для НА, как экономической сущности — понятия «человеческой цивилизации» если и существуют, то не первичны.
Что должно для НА входить в его Scope & Vision?

Какой полный ролевой состав в НА (распределение ролей)?
В контексте статьи ключевым ресурсом является ссылка на статью Олега Кольцова. Процессный подход с точки зрения кибернетики:
============
Лучше вместе с другой моей статейкой «ПРОЦЕССНЫЙ ЛАНДШАФТ И ОРГСТРУКТУРА» :))
process.mirtesen.ru/blog/43852778662/PROTSESSNYIY-LANDSHAFT-I-ORGSTRUKTURA
Вопросы, как автору статей по процессам:
— Ваше мнение о проблеме, показанной в статье Enterprise Architecture vs алхимия предприятия. Ключевые мифы
— как сочетаются BPM и ЕА?
— где найти методичку, как составить реестр процессов компании?
Тему начал здесь: habrahabr.ru/post/343190

Термин «Владелец процесса» означает должностное лицо организации, на которое возложена ответственность за разработку, управление и поддержание в установленном состоянии руководимого им процесса.
Если это (что указано выше) относится к начальнику Х, но за результат этого процесса отвечает У, то владельцем будет все равно Х? Как тогда называть Y?
Может ли быть владельцем — тот, кто вообще не принимает никакого участие в процессе?
Может ли у процесса быть более одного владельца?

Понравился вывод — процессный ландшафт vs ИТ-ландшафт:
Еще одной проблемой определения процессного ландшафта является подмена целей при проведении автоматизации системы управления организацией. При этом цели улучшения и оптимизации системы управления подменяются целями проведения автоматизации ради автоматизации.
Все лениво написать статейку по этим вопросам. Кратко:
1. Реальность слишком сложна для понимания и потому люди для ее понимания придумывают различные модели, представляющие собой упрощенный взгляд с какой-либо стороны. На мой скромный взгляд все модели равноправны, если они отражают характеристики реальности и потому желательно одновременно рассматривать несколько моделей, а не биться головой о пол молясь на единственно правильную.
2. Методички нет потому что реальность слишком сложна при простоте высшего процесса всего живого и организационного — «Выживание».
Реестр процессов появляется при декомпозиции этого процесса.
3. Вопрос двойного подчинения искусственен. Владелец процесса это субъект, определяемый из декомпозиции процесса более высокого уровня, а не назначаемый произвольно. Назначить можно только стрелочника.
4. Исходя из п.3 — не может.
5. Аналогично п.4.
Может ли быть владельцем — тот, кто вообще не принимает никакого участие в процессе?
3. Вопрос двойного подчинения искусственен. Владелец процесса это субъект, определяемый из декомпозиции процесса более высокого уровня, а не назначаемый произвольно. Назначить можно только стрелочника.
4. Исходя из п.3 — не может.

Интересный вывод у Вас:
Значит тот, кто участвует в процессе больше всех, но ему совершенно наплевать на результаты процесса — это Владелец процесса.
Соответственно, этот «владелец» выстраивает процесс так, чтобы был нулевой результат (ему все равно), но главное — чтобы процесс был для него комфортным, т.е. главное процесс, а не результат!
А тот, кто является заинтересованным в результатах процесса и готов всячески бороться за результат процесса (правда «чужими руками»), — он вообще «никто» (и не участник и не владелец).
Странная логика.

Кроме того, не уловил основы для вывода «5. Аналогично п.4.».
В данном случае, все подразделения — активные участники процесса и все претендуют на звание «владелец». Нужно или считать их как «совладельцами» или по каким-то критериям определять «наиглавнейшего».
2. Методички нет потому что реальность слишком сложна при простоте высшего процесса всего живого и организационного — «Выживание».

Что-то мне это напоминает. Не алхимию ли?
Вы решили меня рассмешить? Или хотите заставить меня написать статейку о том, «Как все запущено?»
Владелец процесса это его субъект, сам процесс это объект его управления. Двухголовое животное это не жизнеспособный мутант. У любого объекта не может быть двух субъектов управления. Двоевластие нежизнеспособно.
Как говорили во времена СССР: «Слава КПСС» не человек, подразделения сами по себе ничего не хотят и хотеть не могут.
Я не виноват в том, что Вы путаетесь в функциях подразделений при матричной структуре, считая что в ней куча владельцев одного процесса.
А декомпозировать процесс выживания слвбо? Без алхимии, только на логике и здравом смысле?
Подсказываю на примере: чтобы выжить нужно найти источник пищи, воды, воздуха (на вершинах гор даже орлы не живут), жилище и далее по списку. Деятельность по поиску всего необходимого может называться процессами, являющихся подпроцессами основного процесса. :))
Ваши доводы звучат как: «знаю, но не скажу». Я надеялся услышать: делай раз, делай два … и получишь список своих бизнес-процессов. Ну, хотя бы высокоуровневых.

А пока вижу только «что — то», что и теорией-то назвать сложно. Ссылок точно нет? Конкретных примеров по инвентаризации процессов компании?

Неужели такой очевидный и первостепенный вопрос — как составить список ключевых бизнес-процессов компании нигде не освещен с практических позиций.
Не нужно голой теории, нужна практическая методика.
1. Вы знаете определение бизнес-процесса? Не лично понимаемое, а стандартное, принятое во всем мире?
2. Вообще-то списки есть, включены в ряд систем управления предприятиями, только они не всем подходят и их механическое перенесение зачастую ставит персонал в полный ступор.
3. А серьезных разработок декомпозиции процессов действительно нет. Слишком сложная и многовариантная задача.
Добавлю определений из одного словаря:
Архитектура
В моделировании процессов – целенаправленное определение места модели в общем фреймворке, описывающем весь бизнес через его составные части. Во избежание неоднозначности в качестве основы для архитектуры можно взять широко известный фреймворк, например предложенный Захманом или производный от него, такой как TOGAF.
Architecture
In process modeling, a purposeful arrangement of models in a framework that describes a whole business in terms of its component parts. These may be created in compliance with well-known frameworks to reduce ambiguity. Examples include architectures based on The Zachman Framework and its derivatives, such as The Open Group Architectural Framework (TOGAF).
1. Вы знаете определение бизнес-процесса? Не лично понимаемое, а стандартное, принятое во всем мире?

стандартное, принятое во всем мире??? Очень смешно. Этому посвятил аж три статьи:
Бизнес-процессы: Как все запущено и запутано. Глава Первая
Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»
Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS

У алхимии не может быть «стандартного», стандарты появятся только на руинах алхимии.

Вообще-то списки есть

Кроме apqc что можете посоветовать?
Архитектура предприятия не алхимия, а ремесло! :))
Мой краткий алгоритм:
1. Берем устав предприятия и внимательно его читаем.
2. Находим высшую цель предприятия и заменяем существительное глаголом, например «Работаем для прибыли». Это доступный нам процесс высшего уровня.
3. Находим в уставе виды разрешенной деятельности и определяем какую из многоперечисленных реально выполняем.
Аналогично заменяем существительное на глагол, полученную деятельность условно говоря получая процесс «Производство продукции». Полученную деятельность рассматриваем как один из подпроцессов второго уровня.
4. Два других подпроцесса идут автоматом: «Управление» и «Обеспечение ресурсами»
5. Процесс производства наиболее просто декомпозировать на основе применения старого сетевого графика, рассматривая стрелочки на нем как его подпроцессы.
6. Анализируем требуемые ресурсы, начиная с инфраструктуры.
7 Из анализа потребностей в ресурсах получаем требуемые процессы обеспечения ими.
8 На основе анализа трудовых ресурсов на основе разделения труда и норм управляемости определяем требуемые подразделения.


-, Возможность и пути автоматизации учета и управления.

Дальше писать лениво. И так если слегка расписать получается статейка. :))
Есть предположение, что например архитектуры городов существуют, а архитектуры предприятий не очень, из-за того, что разнообразие городов не очень разнообразное. Вот тут жители живут, вот здесь отдыхают, вот здесь работают, вот здесь дороги, вот здесь трубы, провода, и т.д. А предприятия существенно разнообразнее. Коммерческие, некоммерческие, государственные, производственные, научные, и т.д.
И предприятия меняются быстрее, чем города. Помогла бы Kodak, Nokia или Sun его архитектура предприятия? Была бы эта архитектура актуальной?
«архитектуры городов» — подразумевает разночтение: архитектура города с позиции зодчества и архитектура города с позиции экономического субъекта.
Также можно сравнивать города по другим также архитектурным особенностям, например, сравните город миллионник с закрытым городом, типа «Саров» (другой менталитет жителей и соответствующий «отпечаток» на его архитектуру, ЕА города).

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

Да и сама ИТ-архитектура предприятия — меняется редко, — уж слишком это дорого и рискованно. Большинство upgrade не меняют ИТ-архитектуру.
Ну мы же под архитектурой предприятия подразумеваем все, что важно для предприятия, а не только ИТ. Так и с архитектурой города, подразумеваем все, что важно для города, а не отдельно зодчество, отдельно экономика.

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

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

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

Возникла мысль, почему города меняеются медленнее. Город — финансовая группа. Городу не нужно меняться быстро, т.к. его риски размазаны среди кучи участников (предприятий). У предприятия риски остаются, ему нужно быстро меняться, чтобы выжить.
приводил из посыла, что внешняя среда изменилась, предприятие измениться не успело. И все, нет больше предприятия.

Пока ЕА руками не поменять, она не изменится. Многое, что и «рукотворное» не меняет ЕА, например, управление тарифами не меняет ЕА, хотя может резко отразиться на «самочувствии предприятия».
У предприятия риски остаются, ему нужно быстро меняться, чтобы выжить.

Это, мне кажется, тоже классической уловкой консалтеров. Они постоянно утверждают о том, что возникли «новые условия», «нужно все менять» и что-то покупать (у них или их компаньонов), «уходить в цифру» (цифровизация \ диджитализация) и прочее.

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

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

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

Но есть и другие аспекты. Количество артефактов и скорость изменений.

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

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

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

off
Когда-то в молодости проникся идеями большой четверки, касательно UML.
Обсудил в коллегами, как же теорию перенести на практику. Решили, а давайте начнем с простого, и потом перейдем в описанию более сложных. Вроде бы все логично. Через пару дней делюсь своими моделями с коллегами. В ответ, вместо восторженных рукоплесканий, слышу: ну это же итак очевидно. Зачем нужна модель в разных срезах, тратить время на ее создание, если итак все просто и очевидно.
И хотя за эти два дня созданные модели мне стали близки, пришлось признать, пользы от них было мало. Пришлось с ними расстаться и забыть про них.

Когда польза UML проявилась в полный рост? Через несколько лет, тогда когда сложность проектов серьезно выросла, и стала такой, что в голове уже не помещались все важные артефакты и их связи. И вот здесь ни у кого из сопричастных не возникало вопроса, а зачем UML и зачем нужна актуализация.

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

Архнадзор смотрит на вас с непониманием.

Не знаю как смотрит Архнадзор, но подход ggo — в русле гоголевской архитектурики (Николай Васильевичу бы понравилось):
«Но обратимся к архитектуре городов. Город нужно строить таким образом, чтобы каждая часть, каждая отдельно взятая масса домов представляла живой пейзаж. Нужно толпе домов придать игру, чтобы она, если можно так выразиться, заиграла резкостями, чтобы она вдруг врезалась в память и преследовала бы воображение…
Масса города имеет уже тем выгоду, что ее вдруг можно изменить, исправить по своему произволу.»

«Об архитектуре нынешнего времени»

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

С непониманием, в том смысле, что архнадзор — субъект, препятствующий изменениям?

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

Что должен делать тот, кто управляет городом? Изменять его под новые условия.

Некоторое время назад должность Главного архитектора города предполагала не только ответственность за зодчество, но и прочие аспекты (togaf view) деятельности города. Что делал архитектор города — выявление перекосов между потребностями и возможностями города, текущими и будущими, и контроль планирования и реализации мероприятий (transformation).

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

Неуместным изменениям.


Что должен делать тот, кто управляет городом? Изменять его под новые условия.

Если изменение необходимо. Так же и архитектура — она не для того, чтобы было легко изменять, она для того, чтобы решать задачи. Если решение задач требует изменения — тогда будет изменение.

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

Ключевое выражение «выявление потребностей и их удовлетворение» — это базовая формула для любых фреймворков ЕА: государства, города, предприятия, малого предприятия, домохозяйства, человека.
Если это верно, тогда архитектура предприятия — чтобы проще изменять предприятие.

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

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

С этим — согласен.
Одним из важных отличий архитектурного подхода в ЕА\ НА от объектов зодчества и процессоров действительно заключается в статичности (во всяком случае, консерватизме).

Изделие «процессор» (как конкретный экземпляр объекта типа «процессор») фактически не претерпевает изменений своей архитектуры на протяжении всего ЖЦ.

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

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

Архитектура НА часто меняется при событиях: «дети выросли», «прежние домочадцы съехали» (другие изменения состава семьи — орг-штата НА), «хозяева НА изменили статус» (вышли на пенсию), изменение бизнес-модели НА: потеря прежних доходов или наоборот «попали в русло и деньги стали сыпаться фактически с неба».

Есть и другие отличия мета архитектур. Например, видимость архитектур т.е. одни видны невооруженным глазом — зодчество, другие — только с применением специальных устройств \ методов (архитектура процессоров).
когда сложность проектов серьезно выросла, и стала такой, что в голове уже не помещались все важные артефакты и их связи.

Да, верно именно об этом ЕА и НА. Только нужен математический аппарат для построения таких моделей, а собственно базовые (типовые) варианты и будут архитектурами — архитектурными стилями предприятий и домохозяйств (ЕА и НА).
Поэтому я также призываю: а давайте начнем с простого, и потом перейдем в описанию более сложных.
Только в открытом доступе нет ни «простого», ни " более сложных". Это и есть одно из подтверждений алхимии в ЕА.
Где-то, наверно, повторюсь. Имхо, если не ссылаться на академические источники, архитектура предприятия — это модель, описывающая разные срезы (реальные или воображаемые) предприятия. И это модель служит ровно для одного — помогать тому, кто управляет предприятием, изменять его (тут немного тавтология, т.к. чуть ранее выяснили понятийную близость управления и изменения).
Соответственно архитектура предприятия сама по себе не может быть статичной или подвижной. Архитектура изменяется с той скоростью, с какой меняется само предприятие.

На этапе строительства предприятия с нуля — возможность переиспользования архитектурных шаблонов — жирный плюс. Да и «строить» с нуля, вообще жирный плюс, любой ИТ-ник подтвердит. Но сколько предприятий «в масле» в год появляется? И сколько продолжает свою деятельность с прошлого года? Что делают вторые? Наверно у них тоже происходят изменения.

В целом потребность в наглядных примерах EA подтверждаю. Слишком много побочной информации. Условно UML for dummies есть, а Archimate for dummies нет, только стандарт.

Но уверенности, что простые объекты подойдут в качестве кандидатов для препарирования под лупой EA, нет.
Про цели никто не упоминает. Все же нужно «плясать от печки», т.е. от целей. Архитектура тюрьмы и архитектура дома отдыха будут отличаться, я так думаю. Аналогично и архитектура домохозяйства будет отличаться в зависимости от целей.
Все лучшее детям — одна архитектура. Бери от жизни все — другая архитектура.
После целей идет главная полезная функция предприятия: родить и воспитать детей — или кайф по полной. И уже под это строится все остальное — сущности и процессы.
Может быть автор цели подразумевал, но не осветил в своей статье?
«И таки да» (с), архитектуры предприятий с аналогичными целями теоретически должны быть идентичными, но еще есть такая поправка как местные условия.
Все же нужно «плясать от печки», т.е. от целей.
Архитектура тюрьмы и архитектура дома отдыха будут отличаться, я так думаю.

Интересно – это как же? Если в монастыре стиля такого-то разместить тюрьму, то что: арки выпрямятся, а колонны изогнутся?
Например, Данилов монастырь – как тюрьма для малолеток в 1930 – м изменила его архитектуру (зодчество)?

Так же и для предприятий: предприятия с разными целями могут иметь идентичную архитектуру. Почему нет?
С данным примером Вы правы, возразить нечего. Одно и то же изделие можно использовать под разные цели. В микроскоп можно смотреть, а можно им и гвозди забивать.
Тогда можно сделать вывод, что понятие «архитектура» в смысле зодчества для предприятий вообще не прменимо. Предприятие — это система, созданная для определенных целей, с соответствующими целям сущностями и процессами.
И всех, кто заводит разговоры об «архитектуре предприятия» сразу приземлять на уровень системы и вести предметный разговор в терминологии систем (сложных и не очень). Тогда всем будет ясно и понятно, о чем речь.
О системах писано немало, и примерам построения систем тоже нет числа.
Термин «архитектура предприятия» заклеймим как шулерство маркетологов.
Что скажете?
Тогда можно сделать вывод, что понятие «архитектура» в смысле зодчества для предприятий вообще не прменимо.

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


Это, правда, совершенно не значит, что термин "архитектура предприятия" некорректен. Есть много разных "архитектур", которые давно не зодчество.


Тогда всем будет ясно и понятно, о чем речь.

Не думаю. Терминология систем — тоже штука не идеально понятная.

Одно и то же изделие можно использовать под разные цели. В микроскоп можно смотреть, а можно им и гвозди забивать.

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

В целом, получается, что все эти предприятия имеют идентичную архитектуру. Но цели у каждого могут быть разные:
Акционеры первого – ставят цели: нарубить как можно больше бабла прямо сейчас (и свалить за бугор, т.к. скоро перевыборы и «крыша может съехать»);
Акционеры второго — ставят цели: нарубить как можно больше бабла в перспективе 3 лет и как-то соблюдать закон, чтобы делать вид «законопослушного» (помним про 300 процентов по Марксу);
Акционеры третьего – работать три года ниже себестоимости, чтобы задушить конкурентов и только после этого «отыграть» все «причитающееся» и «упущенное».
Акционер четвертого – решил: хрен с ней – с прибылью – это вторично, сделаю-ка я отечественный ё-мобиль, так сказать подниму престиж отечественного автопрома, дам соотечественникам веру в свои силы и т.п.

Предприятия же не всегда создают «чтобы делать бабки и как можно больше».
Можно привести другие разные целеполагания, под идентичную архитектуру предприятия.
Если опуститься на уровень процессов, то один и тот же бизнес-процесс может использоваться для разных целей (даже для противоположных).

Термин «архитектура предприятия» заклеймим как шулерство маркетологов.

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

И снова зависит от определения архитектуры.

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

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

Выдвину предположение, что у автозавода не может быть цели. Цель может быть у роли или у процесса.

Терминология четко не определена, поэтому нет однозначного понимания, отсюда и проблемы.

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

Для начала определиться бы с формой и содержанием.

В качестве «формы» можно взять форматку Захмана и наполнить ее содержанием. Кто-нибудь пробовал? Лучше отталкиваться от каких-то базовых подходов: List of things \ List of processes …
Это ни чем не хуже, чем через упомянутые Вами: форма и содержание.

Лучше не мучайте себя архитектурой, а рассматривайте предприятие как систему.

А это как? Парой предложений это вряд ли пояснить.

И если кто-то хочет избавить себя от лишних денег, то не нужно ему в этом мешать.

В большинстве случаев, нас – налогоплательщиков «избавляют от лишних» денег. Причем без нашего согласия.
Если в монастыре стиля такого-то разместить тюрьму, то что: арки выпрямятся, а колонны изогнутся?

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

Lair – мое почтение.
Севильский кафедральный собор = готическая архитектура. Разве нет?

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

Я в статье показывал, что «архитектура» в смысле зодчества и для процессоров и для предприятий, других систем (архитектура системы — как концепция) – имеют одинаковый смыл. В чем противоречие?
Желательно на примерах.

Да, и расскажите, как можно говорить о «текущем» понятии ЕА, если так и нет ни одного примера этой самой загадочной архитектуры (ЕА)?
Например, архитектуру зодчества – пожалуйста – примеров масса, архитектур процессоров – также навалом.
Может нужно начать с рассмотрения конкретных архитектур предприятия и только потом в этих примерах нащупать «архитектурность» и скорректировать общее представление о термине «архитектура» применительно к предприятиям?

Разве это не само собой напрашивающийся путь? Или лучше прятать примеры ЕА и рассуждать об «архитектуре предприятия» с позиции алхимии?
Имхо, тут начали скатываться с частностям. Архитектура зодчества — лишь один из срезов общей архитектуры (пусть будет города, или района). Примерно как ИТ-архитектура для предприятия. Но нам же интересен не один срез, и их некоторое количество?
Но нам же интересен не один срез, и их некоторое количество?

Не понял мысли.
Нам интересны сами архитектуры («сами по себе»). Они образуют конечное и небольшое множество. Огромное множество сооружений, процессоров и предприятий содержат конкретную архитектуру из небольшого множества (архитектурного множества, набора архитектур).
Архитектура зодчества, если я ее правильно понял, применительно к архитектуре здания или города, является лишь одним из срезов (view из приснопамятного togaf'а) общей архитектура здания/города. В общем случае, управляющему/владельцу здания/города интересны не только внешний облик и строительные особенности, но и другие срезы, коммерция, культура, экология, энергия, транспорт и т.д.
Т.е. архитектура зодчества хоть и наглядный пример, но имхо однобокий.
Условно, управляющему/владельцу здания недостаточно иметь только строительные чертежи и арх.эскизы для того же арх.надзора.
Архитектура зодчества, если я ее правильно понял, применительно к архитектуре здания или города, является лишь одним из срезов (view из приснопамятного togaf'а) общей архитектура здания/города

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

В статье про это есть ссылка:
Мне близок взгляд на архитектуру, показанный в dragon1
www.dragon1.com/resources/dragon1/architecture

«Архитектурный подход» (архитектурика, формализация мета архитектур) к описанию предприятия мы сравниваем с аналогичными подходами в зодчестве и электронике (процессоры).

Применительно к архитектуре здания (архитектурный фреймворк зодчества): посмотрев «невооруженным взглядом» на здание типа «храм» и открыв каталог архитектур зодчества, можно соотнести архитектуру конкретного храма с типовой (эталонной).

Наберите в wiki любой собор — и там (в кратком паспорте сооружения, см. справа) будет «готика» (готические соборы) или что-то другое (но конкретное).

Отечественные процессоры с архитектурой х86 были поострены путем послойного копирования топологии американских микросхем. Кстати, подобное для современных процессоров современной капиталистической России давно «не по зубам» ни комерсам, ни ВПК.
Идентифицировать архитектуру х86 можно и программным путем (анализ системы команд, разрядности и т.п.).

Вот с архитектурой предприятия — подобное невозможно.
Пока для формализации и идентификации ЕА нет инструментария, а только субъективный подход и алхимия. Когда-нибудь изобретут метод «объективного контроля» и формализации, научатся «фотографировать» процессы, логические объекты и отношения, далее перейдут к цифровому распознаванию бизнес-процессов и архитектуры предприятия.
Эти технологии будут подобны дистанционному зондированию Земли или раскрытию сети (HP NMM и прочее).

Вот «архитектура города» — действительно дает разночтение. Какой объект рассматривается?
Если объект «градостроительство», то да, родственное «архитектура зодчества». Пример из гоголевской архитектурике привел ранее: habrahabr.ru/post/345424/?reply_to=10590392#comment_10589776

Если рассматривается «город», как объект класса «предприятие», т.е. экономическая сущность (не ИТ-сущность, ведь верно?), то говорить об «архитектуре зодчества» уже нет смысла — это другой объект анализа и городская планировка \ застройка если и будет отражена в описании «Архитектура предприятия», то лишь штрихом, т.к. не является ключевым объектом архитектурного описания (по ЕА-фреймворку).

Вы все про архитектуру городов — про сложные объекты, почему вначале не рассмотреть простые, например, НА? А потом только вернуться к сложным?
посмотрев «невооруженным взглядом» на здание типа «храм» и открыв каталог архитектур зодчества, можно соотнести архитектуру конкретного храма с типовой (эталонной).

… и что такое "эталонная архитектура храма"? Вот конкретно, списком.


Наберите в wiki любой собор — и там (в кратком паспорте сооружения, см. справа) будет «готика» (готические соборы) или что-то другое (но конкретное).

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

как уже говорилось ранее, архитектурный стиль. Вы можете взять три собора, …

как уже говорилось ранее (в статье), архитектурный стиль (в зодчестве) = архитектура. И была ссылка, подтверждающая это (на Вику).
Точно также, как «архитектура предприятия» = «архитектурный стиль предприятия».

Повторюсь, что спорить об архитектурах (стилях) «зодчества» и «процессоров» — это нормально, они объективно подтверждены. Чтобы объективно подтвердить наличие архитектуры у предприятия — для этого нужны как минимум образцы архитектур, которые алхимики не показывают.
Может вообще, нет никаких архитектур у предприятий?

Поэтому, я и призываю, собрать некоторое количество архитектур домохозяйств (домашних хозяйств, как домашних организаций), чтобы хотя бы на них посмотреть, что же такое «архитектура предприятия».
Может быть, сосредоточить усилия на этом? Не передумали? Участвуете (раздел №3 статьи)?

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

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

… опровергающий комментарий вы проигнорировали, я заметил.


Точно также, как «архитектура предприятия» = «архитектурный стиль предприятия».

Нет никакого "точно так же". Нет переноса терминов между архитектурой зданий и архитектурой предприятий.


Может вообще, нет никаких архитектур у предприятий?

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


Что касается наличия разных архитектурных особенностей в одном строении (соборе), то также я показывал, что если изначально у готического собора половину разрушить и пристроить «хайтек», то получится комбинация архитектур.

И снова нет. У этого собора будет одна архитектура (в несловарном значении "совокупность принятых конструкторских решений"), но несколько архитектурных стилей.


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


Но это скорее исключение, чем правило.

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

что такое «эталонная архитектура храма»?

Храмовая архитектура
Там есть список (см. содержание), но он далеко не полный.

И снова нет. У этого собора будет одна архитектура (в несловарном значении «совокупность принятых конструкторских решений»), но несколько архитектурных стилей.

Смотрите Вику: там ОДНА строка: «архитектурный стиль» с ОДНИМ значением, например, «готическая архитектура».
Например, по Вашему же Севильскому
По-Вашему: составители Вики, все как один «опираются на свое обывательско-интуитивное понимание»? Тогда оно, видимо, и есть объективное.

Про архитектуру непосредственно домохозяйства что скажите?
Архитектурные стили и подходы к архитектурам зодчества обсудили предостаточно, нам бы так детально подходы к архитектурам предприятий и домохозяйств обсудить бы (цель статьи).
Храмовая архитектура
Там есть список (см. содержание), но он далеко не полный.

Это список архитектурных стилей, в которых строятся храмы. Нет.


Я повторяю свой вопрос: что такое, конкретно, "эталонная архитектура храма". Приведите пример.


Смотрите Вику: там ОДНА строка: «архитектурный стиль» с ОДНИМ значением, например, «готическая архитектура».

… и что? Вы хотите, чтобы в статье в страницу размером были описаны все нюансы? Неизбежно будут упрощения. Если бы была необходимость в точном определении, сказали бы "доминирующая архитектура".


Про архитектуру непосредственно домохозяйства что скажите?

Скажу, что нет определения, что это такое, и мне это не интересно.

Скажу, что нет определения, что это такое, и мне это не интересно.

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

Если бы не слово "только", я бы даже с вами согласился.


К сожалению, эта статья не про зодчество и архитектуру ее объектов.

Это не оправдывает некорректное использование терминов.

Севильский кафедральный собор = готическая архитектура. Разве нет?

Если вас не смущает, что Patio de los Naranjos — это двор мечети, а Giralda — ее минарет (и, если верить вашему примеру с монастырем, архитектура не должна была измениться). И если закрыть глаза на ренессансные и барочные участки, которых там много.


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

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


Я в статье показывал, что «архитектура» в смысле зодчества и для процессоров и для предприятий, других систем (архитектура системы — как концепция) – имеют одинаковый смыл. В чем противоречие?

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


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


Может нужно начать с рассмотрения конкретных архитектур предприятия и только потом в этих примерах нащупать «архитектурность» и скорректировать общее представление о термине «архитектура» применительно к предприятиям?

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

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

«нужно начать с рассмотрения конкретных архитектур предприятия» хотя бы тех «архитектур», которые существуют в понимании консалтеров (архитекторов).

Проектов по ЕА много. Даже если там и описание не ЕА (но выдается за ЕА, т.е. как с надписью на сарае, где дрова лежат), то хотя бы будет «хоть что-то, что можно сравнивать хоть с чем-то».

Зачем спорить о том, какого цвета что-то, что мы не видели? Лучше посмотреть на томик проекта с заглавием ЕА и сказать какого оно «цвета», т.е. о какой архитектуре вообще речь.
Пока алхимики лишь говорят, что они всё видели и знают толк в «настоящей архитектуре».
Только такой ответ меня не устраивает.

вы не знаете, что именно в предприятии рассматривать.

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

Вот алхимикам и приходиться хитрить: «мы работаем только со сложными системами — Масштаба предприятия и только по NDA, а простые примеры ЕА рассматривать не желаем, т.к. это „не наш уровень“.
«нужно начать с рассмотрения конкретных архитектур предприятия» хотя бы тех «архитектур», которые существуют в понимании консалтеров (архитекторов)

А, благое начинание. Удачи.

Спасибо.
Помощников и сподвижников бы. В одиночку армию алхимиков не одолеть.

… и вы удивляетесь, почему никто из занимающихся EA не хочет с вами сотрудничать?

… и вы удивляетесь, почему никто из занимающихся EA не хочет с вами сотрудничать?

То, что «профессионалы» (помните хоккейного комментатора: «канадские профессионалы» и «советские любители») не будут сотрудничать — в этом сомнений давно нет. Это обсуждали:
Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»
habrahabr.ru/post/300986/#comment_9637178

< … на мой взгляд, часть алхимиков осознаёт, что они выглядят алхимиками — тот же …

<< Они почти все это понимают. Только, к сожалению, они нам не помогут.

Мой расчет на «любителей».

А тогда не видать вам, собственно, "конкретных архитектур в понимании консалтеров".

Вопрос об отличиях архитектуры тюрьмы и дома отдыха довольно спорен. Например тюрьмы www.infoniac.ru/news/Samye-shikarnye-tyur-my-mira.html получше многих домов отдыха. Я уже не говорю про то, что люди уже давно знали что «золотая клетка» по своей сути тоже тюрьма.
И как разобраться? Может быть на основе какого-нибудь существующего «знатного фреймворка»? Или Вы свой предложите?
Согласен.
С трудом верится в такие тюрьмы. Туда видимо очередь на несколько лет вперед, а тех кто сбежал – сразу в психушку: как можно cбежать от такой райской жизни будучи в здравом уме? Может это просто «буржуазная пропаганда»? Хотя есть и другие объяснения.

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

Например, за пребывание, как в пансионате, так и в такой странной «тюрьме» идет посуточная оплата «постояльца» или «арестанта».
Речь о коммерческих тюрьмах? За пребывание в таком «доме отдыха за колючей проволокой» он платит (а ценник не менее, чем за пребывание в отеле), а как только деньги закончились — его сразу в «настоящую тюрьму»?!
Тюремщики выполняют роль «следящей сиделки», о перевоспитании, скорее всего, речи нет. Т.е. основная цель тюрьмы – в этом случае исключена, т.к. арестант находится «на отдыхе» в «закрытом пансионате» купив «освобождение от классического наказания».

Думаю, при детальном рассмотрении ЕА обоих предприятий, действительно выяснится их единое «архитектурное начало».

На этом примере отчетливо видна суть «буржуазной системы» (или даже – «буржуазной архитектуры»): деньги решают все!
В советской (справедливой) архитектуре, у арестанта вначале бы конфисковали все активы, поэтому ему нечем было бы платить за подобную «индульгенцию».
Эти тюрьмы есть в реале. И они зачастую государственные. То есть для ЗК они бесплатны!
Как туда попасть человеку с российским паспортом?
Какие требования к кандидату?
Знание местного языка обязательно?
Я рассматриваю Togaf как рекомендации для того чтобы:
— последовательно, пройдя все необходимые этапы (requirements, uses cases, point of views, application, data, technology architecture и тд) реализовать какую-то цель/стратегию/задачу бизнеса посредством ИТ
— упорядочить и поддерживать ИТ документацию предприятия состоящую из таких документов как принятые стандарты, описание ПО используемого в организации (это могут быть различные виды описания — просто диаграмма, детальное описание компонентов на уровне данных, инфраструктуры и тд)
— управление архитектурой как на уровне организации в долгосрочной перспективе (architecture board) или на уровне определенного ПО организации

В Togaf очень много деталей, но личный выбор каждого выбрать наиболее необходимые/приемлимые моменты. Все это не есть какое-то изобретение Open group, в том или ином виде подобные вещи существуют и практикуются повсеместно. Open group объединила их в документацию и выставила в свободный доступ. Иметь или не иметь сертификат — дело сугубо личное. Обвинять Open group в жадности не вижу смысла.
Open group объединила их в документацию и выставила в свободный доступ.

Вы — как практик ТОГАФ, ответьте, пожалуйста, на вопрос: почему, несмотря на наличие в открытом доступе «пособий по алхимии» (этого и других фреймворков), — нет примеров описания предприятий по этим пособиям?

Сделали бы (сам Open group или сертифицированные им специалисты) несколько «учебных», но полных и конкретных. В чем проблема?

Вы знаете о наличии конкретных примеров описания ЕА, доступных «простым смертным» (не алхимикам)?
Я не опираюсь на конкретные примеры, а применяю рекомендации Togaf основываясь на моем понимании/интерпретации, а так же не малой долей здравого смысла. По началу приходиться по много возвращаться к документации вновь и вновь, искать в гугле подтверждение (или нет) правильности понимания. Только реальное применение позволит (субьективно) правильно разложить все по полкам, получить ответы на возникающие вопросы.

Architecture repository у меня организован следующим образом:
  • Architecture landscape
    • Strategic architectures — описание предприятия высокого уровня — на примере Амазон это может быть список ключевых сервисов (retail, aws и так далее)
    • Segment architectures — описание определенного бизнес домена предприятия — на пример более подробного описания сервисов aws
    • Capability architectures — описание конкретного aws сервиса, например S3
  • Reference library
    • Reference models — например модель описывающая big data aws, azure или google
    • Reference architecture — более подробное описание с названиями ПО, взаимосвязями опять же на пример для big data
    • Templates — различные шаблоны для ИТ документов

  • Standards information base
    • Список различных стандартов предприятия помогающих архитектору реализовать задачу (все что угодно — SLA, безопасность и тд)
    • Список стандартных и поддерживаемых решений предприятия — модели серверов, СХД, сетевых устройств, ПО для базы данных и тд
  • Architecture building blocks
    • Шаблоны архитектур для различных компонентов (веб сервер) и их конкретная реализация про помощи того или иного решения (Apache)



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

Важно чтоб превалировал здравый смысл, а не слепое и тотальное следование рекоммендациям Togaf.
Спасибо за подробный ответ.
Правильно я понял, что в Вашем понимании у предприятия, у которого нет ни одного компьютера нет и «архитектуры предприятия»?
Иначе что записывать в указанный Architecture repository?
Togaf определяет несколько типов архитектуры (http://pubs.opengroup.org/architecture/togaf9-doc/arch/), в вашем случае будет бизнес архитектура описывающая структуру предприятия, роли, сервисы, продукты, сценарии (купил-продал) и тд.

На самом деле не стоит применять Togaf на все случаи жизни, эта методология все же специфична для ИТ.
эта методология все же специфична для ИТ.

Какую посоветуете методологию ЕА и фреймворк, которые не «специфичны для ИТ»?
Перенес в начало, т.к. слишком большое вложение получилось (проследить дерево сложно):
habrahabr.ru/post/345424/?reply_to=10588288#comment_10588288
1. Берем устав предприятия и внимательно его читаем.
2. Находим высшую цель предприятия и заменяем существительное глаголом, например «Работаем для прибыли». Это доступный нам процесс высшего уровня.
3. Находим в уставе виды разрешенной деятельности и определяем какую из многоперечисленных реально выполняем.
Аналогично заменяем существительное на глагол, полученную деятельность условно говоря получая процесс «Производство продукции». Полученную деятельность рассматриваем как один из подпроцессов второго уровня.
4. Два других подпроцесса идут автоматом: «Управление» и «Обеспечение ресурсами»
5. Процесс производства наиболее просто декомпозировать на основе применения старого сетевого графика, рассматривая стрелочки на нем как его подпроцессы.
6. Анализируем требуемые ресурсы, начиная с инфраструктуры.
7 Из анализа потребностей в ресурсах получаем требуемые процессы обеспечения ими.
8 На основе анализа трудовых ресурсов на основе разделения труда и норм управляемости определяем требуемые подразделения.


-, Возможность и пути автоматизации учета и управления.

Дальше писать лениво. И так если слегка расписать получается статейка. :))

Алгоритм для BPM или ЕА?
Дальше писать лениво. И так если слегка расписать получается статейка. :))

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

На конкретном примере (хотя простом, например, булочной) можете показать?

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

А если там «малоперечисленные» или многие из реальных бизнес-процессов напрямую не вытекают из пункта №2?
8 На основе анализа трудовых ресурсов на основе разделения труда и норм управляемости определяем требуемые подразделения.

Что за нормы управляемости? Основы разделения?

Может быть, проще у самих подразделений спросить: в каких процессах они задействованы? Мы же делаем описание (архитектурное) «как есть».
1. Алгоритм универсален и не раз проверен на практике.
2. Ответ на все Ваши вопросы (с примерами) тянет на целую книгу.
3. Посмотрите Устав любого ООО «Рога и копыта». В перечне видов деятельности чего только не пишут, вплоть до защиты государственной тайны, хотя реально — ларек с пивом.
4 Нормы управляемости известны с древних времен. Один начальник может непосредственно управлять только ограниченным количеством подчиненных (в зависимости от сложности исполняемой ими работы). Обычно около 10 человек. Даже в порядочных гаремах назначают старшую жену и главного евнуха чтобы не утонуть в разборе мелочевки.
1. Алгоритм универсален и не раз проверен на практике.

Повторный вопрос — ссылка?
2. Ответ на все Ваши вопросы (с примерами) тянет на целую книгу.

Хоть что-то бы и хоть с каким-нибудь куцым примерчиком. Ведь реально имеем «ноль».
В перечне видов деятельности чего только не пишут, вплоть до защиты государственной тайны, хотя реально — ларек с пивом.

Это не только с уставом. Со многими другими артефактами тоже, включая описание бизнес-процессов, см. заставку к
habrahabr.ru/post/305720
as really is
Однако, наверняка изобретут метод «объективного контроля» и формализации (фотографирования, цифрового распознавания бизнес-процессов и т.п.).

Жаль, но конкретными примерами Вы нас пока не порадовали (надеюсь что увидим).
Хотя посыл «что всё знаете» — донесли четко («не раз проверен на практике», «дальше писать лениво» и т.п.).
Вы когда-нибудь были на лекциях или семинарах иноземных Гуру? Мне запомнилось главное: В самом рассказе все излагается как для неграмотных дебилов, а на любой конкретный вопрос следует ответ: «Это консалтинговый вопрос. Мы на него ответим только после заключения договора на консалтинг!» :))
Здесь Вашу статью с примерами обсуждают или мою? :))
Это я к тому, повторюсь, что если мне подробно и с примерами отвечать на Ваши вопросы, то мне надо написать минимум брошюру, а то и целую книгу. Требовать такое количество материала как минимум неприлично. Не тот формат. :))
С примером по гуру — согласен. Также говорят и алхимики ЕА, про это указал в п. 1.3.1:
Попытки «Посмотреть на конкретный пример ЕА» все как один (два): или «купи проект по ЕА» или (самый дешевый) «пройдите наш платный курс, мы вам ТАМ покажем (и то «по очень большому секрету»)».
Требовать такое количество материала как минимум неприлично. Не тот формат. :))

Нет, — так нет. Хотя не понятно почему не привести хотя бы пару малюсеньких конкретных примерчиков.

Надеюсь Вы в конкурсе на простую НА (см. п. №3) поучаствуете? Пожалуйста, очень просим.
Тем самым Вы внесете существенный (или скромный, все от Вас зависит) вклад — как в борьбу с алхимией и наукообразием в ЕА, так и в сотворении научного архитектурного подхода (архитектурика) к описанию предприятия типа «домохозяйство».
Надеюсь Вы в конкурсе на простую НА (см. п. №3) поучаствуете? Пожалуйста, очень просим.
Тем самым Вы внесете существенный (или скромный, все от Вас зависит) вклад — как в борьбу с алхимией и наукообразием в ЕА, так и в сотворении научного архитектурного подхода (архитектурика) к описанию предприятия типа «домохозяйство».

Лучше я Вам предложу статью с сайта мелкомягких по этому вопросу:
msdn.microsoft.com/ru-ru/library/ee914379.aspx
Повторюсь: теорий — «как грязи», только их апробаций не найти.
Нужна «хорошая теория» — по — Ленину (практичная).
Я в последнее время вообще предпочитаю примеры из сказки.
habrahabr.ru/post/346582
Рассказ о реальной практике чреват обвинением в разглашении коммерческой тайны.
Я в последнее время вообще предпочитаю примеры из сказки

Я примеры из мультиков:
Он и меня посчитал!
habrahabr.ru/post/343190
Рассказ о реальной практике чреват обвинением в разглашении коммерческой тайны.

Меняем фамилии, пароли, явки. Добавляем фразу: все совпадения с реальными событиями случайны и т.п.
Методик, эталонных моделей и архитектурных фреймворков (обычно с окончанием на «AF»: FEAF, TEAF, DoDAF и т.п.) — «как грязи», а реальных результатов посмотреть негде.

Если поискать, то найти можно. Вот например Nepal Government Enterprise Architecture на TOGAF от PWC: www.mope.gov.np/download/090_Nepal%20GEA%20-%20Main%20Report%20v2.0.pdf.4475808bc7ebb4df54affb67744a1c46
Добрый день!

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

togaf, archimate, models, examples, enterprise architecture
Что за херня тут написана? Это надо чувствовать, а не зубрить!
Sign up to leave a comment.

Articles