Алхимиками двигало примерно то же, что и современными учёными — им хотелось понять, как устроен мир. Они изучали это как могли. Позже древние протонауки эволюционировали до современного состояния наук.
Это справедливо и для современной дисциплины «Архитектура предприятия», нужно лишь сделать два уточнения: «алхимиками в 21 веке двигало …» и «… понять, как устроено предприятие».
На страницах ИТ-интернета тема Enterprise Architecture (ЕА) — одна из популярнейших. Она дает возможность поговорить о «высоком», — об «архитектурном» подходе, десятках framework, почувствовать себя Архитектором «с большой буквы».
Пишут многие и пишут много. Читатели статей «Архитектура предприятия» одобрительно кивают, восхищаясь … «платьем короля». На «благодатной почве» ЕА развелись всевозможные «архитекторы».
Книги, учебные дисциплины, консалтинговые проекты, группы, консорциумы, целые институты со специализацией ЕА (IFEAD, iEAi и др.), глобальные организации (GEAO), одноименные журналы (Journal of Enterprise Architecture), международные стандарты (ISO 15704, 42010 и др.) и прочее — прочее.
Тем не менее, в контексте ЕА, остаются вопросы: что такое «архитектура», что такое «предприятие» и что такое «архитектура предприятия», а также — кто главный потребитель ЕА и почему конкретных примеров этой самой ЕА нигде нет.
Методик, эталонных моделей и архитектурных фреймворков (обычно с окончанием на «AF»: FEAF, TEAF, DoDAF и т.п.) — «как грязи», а реальных результатов посмотреть негде.
Да-да, ключевая особенность этого направления: нет ни одного конкретного полного примера этой самой загадочной enterprise architecture в открытом доступе.
Архитекторы говорят, что это NDA, «большой секрет», ДСП (возможно даже «гос-тайна»). Но как вообще «архитектура» может быть секретной? На то она и «архитектура», чтобы быть узнаваемой: различимой и сопоставимой. А вот «Алхимия предприятия» — как раз и должна держаться в строгом секрете.
В качестве «лакмусовой бумажки» — как подтверждение или опровержение к сделанным в статье выводам объявляется конкурс на описание своей «household architecture», см. конец статьи. Зачем браться за решение сложных задач, если нет возможности решить простую задачку – привести описание архитектуры своего домохозяйства на тех же framework, что и ЕА?
Пытаемся разобраться в модном и одновременно сказочном Enterprise Architecture.
Удивительно: до сих пор не понятно, что же такое просто «Архитектура предприятия» (типа «аналоговая»?), а за окном уже во всю трубят «о сверхновой звезде»: «Цифровая архитектура предприятия», Digital Enterprise Architecture.
1 Мифы Enterprise Architecture
1.1 A framework for information systems architecture
Начнем с самого популярного мифа. Это когда делается подмена «архитектура предприятия» на «архитектура информационных систем предприятия». ЕА – это совсем не ИТ-архитектура и если на листе с заголовком «Архитектура мебельной фабрики» увидите большие квадраты с надписями SOA или подобными страшилками из мира ИТ, то знайте: это или «нелепое недоразумение» (заблуждение) или «классическая» сознательная подтасовка.
Забавно выглядит картина, когда директору предприятия приносят картинки (схемы) с заголовком «Архитектура предприятия», где более 90% объектов – названия из ИТ.
На это директор говорит: «я управляю предприятием 15 лет, но не понимаю более 90% указанных вами названий (в первый раз вижу «SOA, корпоративное облака» и т.п.), вы хотите сказать, что я не знаю архитектуру своего предприятия?» Это к вопросу о потребителях ЕА.
Большинство известных описаний структур, «каркасов», подходов к описанию, принципов, каркасных методологий (фреймворков) были созданы именно под описание ИТ-архитектуры, архитектуры информационных систем. Изначально, 1984- ом, что в 1987- ом, что в 1992-ом, у них были именно такие названия, например, «A framework for information systems architecture» J. A. Zachman
Zachman87 (5х3)
Zachman92 (5х6)
Точнее использовано название ISA framework (information systems architecture).
Спустя время, через понимание «что нужны иные масштабы», с «легкой» руки ИТ-гигантов, в том числе IBM (там работал Дж. Захман) «структуру архитектуры информационных систем» стали называть (подменять) «структурой архитектуры предприятия». С помощью такой «магии» произошел «качественный переход» от обсуждения ИТ-элементов (артефактов, сущностей) к обсуждению «предприятие-строения».
Это уже иные масштабы, иные ценники и бюджеты (ЕА задешево не бывает), иной статус направления \ дисциплины.
Одно дело «моделирование ИТ» и совсем иное – «моделирование бизнеса \ моделирование предприятия». Нечто подобное, «магическая» подмена понятий по термину BPM была показана в Бизнес-процессы: Как все запущено и запутано. Глава Первая
Легенда от ИТ гласит: подходы к построению ИТ-архитектуры в последующем были обобщены для рассмотрения не только ИТ-систем, но и для описания предприятия в целом. Но это спорное утверждение, т.к. до сих пор нет убедительных примеров (подробных примеров ЕА в открытом доступе).
Итак, нужно научиться различать настоящую ЕА и «архитектуру информационных систем предприятия». Это «две большие разницы» (мухи и котлеты). Настоящая ЕА – начинается с того, что в ней правильно применены оба слова в ее названии.
Иногда применяют термин «системная архитектура предприятия», что является синонимом «архитектура информационных систем предприятия», «ИТ-архитектура». При этом, часто уточнение (приставку), что это именно «системная» или «ИТ» архитектура — опускают и говорят, как бы «про настоящую» ЕА, но в терминах ИТ. Плюс термин в зависимость от эпохи: «цифровизация», «автоматизация», «информатизация».
Таким образом, осознанно или нет, но происходит подмена понятий, исходного понимания назначения вводимых терминов.
Происходит подмена ценностей: вместо изначальных — построение некого математического аппарата, прообраза новой инженерной дисциплины, а может быть и научного направления, — происходит «скатывание» до пира с целью монетизации идей ЕА и подходов к ее описанию, которые остались еще на уровне алхимии. Это ключевой вектор критики Enterprise Architecture.
1.2 Миф второй — «архитектурный»
Придумано много «умных» подходов: процессный, проектный, системный, комплексный, программно-целевой и другие «правильные» подходы. Попробовал бы кто-нибудь заявить, что он полагается на несистемный подход или некомплексный.
В большинстве случаев, вместо «красивого» упоминания «правильного подхода» лучше привести конкретику, например в случае «системного» — привести схему этой самой системы.
Логично было бы предположить, что при рассмотрении направления «Архитектуры предприятия» использован архитектурный подход. Что это такое? Еще один «правильный» подход?
Когда люди произносят слово «архитектура» — они чаще всего имеют ввиду архитектуру зданий и сооружений, т.е. применительно к зодчеству.
Но термин «архитектура» имеет более широкое понятие, более глубокий смысл. Но не такой, какой принято подразумевать (алхимиками) в ЕА.
Почему-то в интерпретации «ИТ-ориентированных законодателей моды в ЕА» (включая ИТ-архитекторов и CIO), название ЕА — это некая область в ИТ и что понятие «архитектура» в ЕА имеет особый смысл (не общеупотребимый к термину «архитектура») лишь на основе принципа: «кто первый встал, того и тапки». Почему на картинках, отображающих якобы ЕА, в основном нарисованы ИТ-объекты? Идет отсылка к ИТ-стратегии и т.п.?
И все это, несмотря на то, что wiki дает вполне объективное название (вообще без упоминания ИТ):
Архитектура предприятия (EA) — это дисциплина для проактивного и целостного руководства предприятием посредством реагирования на разрушительные силы благодаря выявлению и анализу необходимых изменений в направлении желаемого видения бизнеса и последствий.
www.gartner.com/it-glossary/enterprise-architecture-ea
Вика дает не менее туманный ответ: en.wikipedia.org/wiki/Enterprise_architecture
Архитектура предприятия (EA) — это четко определенная практика постоянного (вечного!) проведения анализа, проектирования, планирования и реализации предприятия с использованием комплексного подхода в целях успешной разработки и реализации стратегии.
Определений ЕА существует так много и таких разных, что говорить об ЕА — как о чем-то однозначном — бессмысленно.
What is EA?
What is Architecture?
1.2.1 СубМиф «детальности»
Иногда под описанием «архитектуры» понимают детальное описание конкретных элементов рассматриваемого объекта (предприятия и его составных частей), вплоть до детализации типа спецификация, рабочий проект \ рабочая документация (применительно к ГОСТ по стройке или АСУ). Архитектура – это не детальное описание.
Термин архитектура – носит концептуальное выражение, описание архитектуры – это описание концепта, концептуальной модели, общих «архитектурных элементов» конструкции типа предприятие (описание каркаса, скелета).
Могут быть суб-архитектуры, микроархитектуры, наноархитектуры, но все равно – это некие концепты, общие модели, общие принципы построения, стили. Причем это правило (как минимум, правило русского языка) «работает» для архитектуры здания (зодчество), архитектуры процессора (архитектура х86, микроархитектуры) и многих других правильных употреблений термина «архитектура».
Примеры
Применительно к зодчеству: стиль и разновидность архитектуры – это синонимы:
древнегреческая архитектура, Архитектура Древнего Рима и т.п.
Архитектура Древнего Рима употребляется ровно также как и Архитектурный стиль Древнего Рима.
Принципиальный момент: предприятия должны " отличаться ", но их архитектуры — нет! Во всяком случае, утверждение: «каждому предприятию — своя уникальная архитектура» — это не верно. Для того и придуман термин «архитектура».
Архитектура — это некий каркас (некие элементы типа ребро, арка, колонна, выстроенные в определенном порядке, задающем определенного вида каркас), общие подходы к построению здания или предприятия. Зданий разных много, но именно архитектур — мало.
Например, вне термина архитектура следующие подходы:
- различие по масштабу: и «большие» и «маленькие» могут иметь одну и ту же архитектуру;
- различие по материалу изготовления: здание с архитектурой «пирамида» может быть изготовлено из многих вариантов материала.
Микропроцессор одной и тоже архитектуры может быть изготовлен по разным технологиям (топология).
Посмотрим на «Архитектура процессора», наберем в гугле «архитектура х86».
Все картинки примерно одинаковые: шина данных, шина адреса, шина управления и т.п. Совершенно разные компьютеры (от embedded до high-end серверов) могут иметь одну и ту же архитектуру (х86).
Почему предприятия так не могут? С «архитектурными подходами» в зодчестве и микроэлектронике (и других сферах) — все понятно. А вот с EA — нет, в нем в понятие «архитектура» — вкладывают иной, особый смысл (маркетинговый). Зачем?
Применительно к ЕА, «архитектура» — это высокоуровневое представление (обобщенная структура объектов и процессов, концепция предприятия), описывающая в структурированной форме ключевые компоненты и деятельность предприятия вне зависимости от конкретной организационной структуры или ИТ-системы.
Модель, но не конкретная модель конкретного предприятия, а концептуальная высокоуровневая полная (разных его составляющих и не обязательно ИТ-составляющей) модель определенного класса предприятий. По этой теме была дискуссия, см. комментарии от «bipiem» habrahabr.ru/company/technoserv/blog/343350
Наука ЕА должна включать не только «скелеты» — фреймворки, некие методики и пособия по описанию архитектуры, но, прежде всего, референтные (эталонные) модели типовых архитектур предприятий. Она должна быть нацелена на стандарты и свободный обмен архитектурами. Вторичным являются подходы к описанию и нотации: какими квадратиками и кружками на схеме обозначать объекты ЕА.
У каждого предприятия есть архитектура (концептуальная высокоуровневая модель), также как архитектура есть и у каждого здания и процессора. Она может быть типовой или уникальной, но всегда это концепция.
Уровень абстракции архитектуры — ограничен, т.к. «концептуальное» и «детальное» — взаимоисключения. Утверждения, что все «предприятия уникальны, поэтому их ЕА специфичны (неповторимы), т.е. ЕА всегда уникальна» — это то же самое, что утверждения «все здания одной архитектуры уникальны». Да, здания уникальны, но их архитектура – нет (за редким исключением).
Для детального рассмотрения предприятия может быть применен подход рассмотрения «предприятие — как изделие» с полным комплектом чертежей «как устроено предприятие», вплоть до «каждого винтика».
Начинается такой комплект со Схемы деления изделия на составные части и продолжается описанием каждого обеспечения, включая программное (см. ГОСТы на АСУ 24.ххх или 34.ххх, РВ 15.ххх). Заканчивается такое представление ответом на вопрос: как изготовить (разрабатываемый компонент) или купить (покупное изделие) любой элемент (винтик) системы под названием «Предприятие». Но это не архитектурное представление.
Выдавать архитектуру – за описание конкретных алгоритмов, взаимосвязь объектов (одних элементов с другими) – это значит, из архитектурного представления пытаться сделать еще один тип (класс) конструкторской документации.
Т.е. описание архитектуры – это не конструкторская (рабочая) документация (как это устроено?), не эксплуатационная документация (как это эксплуатировать?) и не технологическая документация (как это изготовить?) в привычном представлении ГОСТ или аналогичных западных систем стандартизации (за исключением алхимии BPM & EA).
Описание ЕА — это не детальное рассмотрение, а лишь попытка выявить архитектурные особенности (через абстракции) и сопоставить их с другими архитектурами, найти общее и разное для соотнесения архитектуры предприятия к какому-либо виду (стилю, разновидности, концепту).
Если речь о детальном описания работы предприятия, всех его бизнес-процессов, взаимозависимостей между бизнес-объектами и ИТ — объектами, формализации логических структур предприятия и его отдельных устройств (компонент), то это так и нужно называть: полная (абсолютная) документация на предприятие, а процесс — разработка комплекта конструкторской документации на него.
Если дело лишь в этом, то не нужно делать «из мухи слона» и устраивать «ЕА-эйфорию». Достаточно взять за основу принципы описания «изделия»: что «саперная лопата» или «подводная лодка», что АСУТП или «АСУ стратегическими ядерными силами» — принципиальной разницы нет. Кладут вам на стол комплект документации «лопата» или «предприятие» и можете его отдавать на завод – вам изготовят точно такое же.
По техническим условиям (ТУ) вы можете проверить соответствие изготовленного предприятия (изделия) комплекту документации и знать про «каждый винтик предприятия», вплоть до его кода по спецификации и номера листа, где он показан.
Многие гуру за детальное описание ЕА, но многие консалтеры возражают: детальное описание ЕА — это распыление ресурсов на описание всех элементов архитектуры, и этого делать не нужно, а нужно лишь описывать «архитектуру», причем конкретно и детально, но «не всю».
Однако, граница — где еще детали, а где уже «архитектура» — это видимо дар, «выданный» только консалтерам. Это, как правило, «гибкость» инструмента или фреймворка, «адаптация» общего метода (методики) на специфику предприятия, «грамотное» применение «Лучших практик», т.е. полная ересь, которая оправдывает неэффективность используемых подходов и маскирует алхимию.
Мне близок взгляд на архитектуру, показанный в dragon1
Концепция определяется как подход, абстрагированный от его реализации. Приведен пример архитектурной концепции «амфитеатр» и реализации — Колизей, как объединение принципов строительства стадиона и театра в типичное для Рима сооружение — амфитеатр.
Удивительно то, что на обложках многих книг и статей по ЕА подчеркнуто нанесены изображения древних архитектур зодчества, тем самым, намекая на заимствование подхода, однако в дальнейшем классический архитектурный подход искажается в ЕА переходом в детали реализации и в ИТ плоскость (магическая «цифровая трансформация»).
Сколько нужно страниц А4, чтобы показать архитектуру? Если по Захману – то одной в формате ландшафт (30 клеток) должно быть достаточно?
«В популярных книгах EA, фреймворках, например, TOGAF или IAF, и даже в академических статьях предлагается, чтобы EA предоставляла исчерпывающие описания текущих и будущих состояний организации, а также дорожную карту перехода между ними.
По сути, основная литература EA обычно описывает EA как толстую «книгу», полную различных диаграмм с четырьмя различными «главами»: бизнес-архитектура, архитектура данных, архитектура приложений и технологическая архитектура.
Известный гуру EA Jaap Schekkerman утверждает, что EA является «полным выражением (описанием) предприятия». Соответственно, основные подходы к EA, например TOGAF ADM, показывают, что EA, как всеобъемлющая книга, разрабатывается поэтапно, по главам, а затем используется в качестве инструмента планирования.»
Взаимосвязь между артефактами архитектуры предприятия
Восемь существенных артефактов архитектуры предприятия
Т.е. всеобъемлющее описание всего предприятия вплоть до «винтика» и каждого «процессика»? Да еще в «as is» + «to be» + «roadmap»? В большинстве случаев все три составляющие устареют, пока толпы архитекторов подойдут к финишу (закончат свою ЕА-поэму).
1.2.2 СубМиф «уникальности»
Следуя выше показанному подходу: «архитектура» не предполагает детальное описание объектов и артефактов предприятия, включая ИТ-ландшафт, структуру конкретных ИТ-объектов и ИТ-артефакты. «Архитектуры» – как некие концепты, которые должны быть сравнимы (в этом и назначение подхода) и абстрагироваться от «конкретного».
Каждому предприятию – своя уникальная архитектура – это «маркетинговая уловка» (management fad), насаждаемая консалтерами (выгодная позиция для увеличения продаж). Никто же из них не утверждает: каждому процессору – своя собственная уникальная архитектура, каждому зданию – своя неповторимая.
В ряде случаев возможна разработка уникальных архитектур предприятий, но это сопоставимо с разработкой новой архитектуры процессора, архитектуры вычислительного процесса, нового архитектурного стиля в зодчестве и т.п., включая «открытие новой звезды».
То есть, это исключительный случай, требующий совершенно другого уровня проработки, затрат и рисков, т.к. чаще всего это влечет отказ от типового, унифицированного, стандартизованного, апробированного. Даже если речь идет лишь о комплексировании (сборки) новой архитектуры из заимствованных блоков из других стандартных архитектур (ЕА).
Архитектуры предприятий должны быть классифицированы и стандартизированы. Их не должно быть много. Их и не может быть много, т.к. это «концепты», «каркасы», «опорные конструкции предприятия» (балки и скелетоны). Но для этого (сравнения и классификации) нужно их увидеть (опубликовать).
Во всяком случае, с позиции ЕА два предприятия могут иметь идентичную архитектуру даже если в одном из них «все на Microsoft», а в другом «все на Linux» или в одном «все на ИТ» (высокий уровень автоматизации), а в другом вообще нет компьютеров (нулевой уровень автоматизации). ИТ-архитектуры могут быть разные, но ЕА — архитектура идентична.
Картинка про «уникальность ЕА» и «гласность ЕА» показана в следующем параграфе.
1.3 Миф «голый король»
Бывают случаи, когда какое–либо явление или объект не видимы невооружённым глазом. Однако они принимаются на веру, т.к. по ним есть научные обоснования их существования, которые можно или косвенно проверить или есть непротиворечивая строгая теория.
В противовес такому подходу есть широко распространённый в бизнесе (пиар-составляющей) и воспетый в сказке эффект «голого короля».
Применительно к ЕА склоняюсь к такому эффекту, потому что предприятий – «пруд пруди» — и у каждого даже самого маленького есть архитектура (надеюсь это не оспаривается), самих архитекторов развелось – «как @ …», книг, курсов, тренингов, общих подходов, каркасов – фреймворков – гига-тонны электронной макулатуры.
Но вот нет ни одного примера этой самой загадочной ЕА. Почему?
Легенда фаворитов «голого короля» гласит: ЕА существует! Она уникальна для каждого предприятия. Публиковать ее в открытом доступе – нельзя, т.к. это конкурентное преимущество перед врагами (конкурентами). Описание ЕА сократит конкурентное преимущество, т.к. враг поймет, какая у вас (замечательная) архитектура! ЕА – это самая большая коммерческая тайна предприятия, и ее нужно хранить в секрете, как и величину зарплат у менеджмента предприятия.
Поэтому конкретику по ЕА никто не публикуют, защищают NDA и т.п.
Чем невероятнее глупость – тем легче в нее поверить. Начнем с того, что ЕА – это концептуальный уровень (по определению) и никаких IP-адресов там нет. Ничего секретного в ней нет, кроме того, что это чаще всего макулатура с очень нешуточной стоимостью (вот это действительно два больших секрета).
Поэтому для консалтеров — NDA, а в самих компаниях — это «ДСП», вплоть до «сведения особой важности».
Как только начнут публиковать реальные ЕА, образуется «неловкая пауза» — а зачем столько денег было «на это» затрачено? Хотелось бы ошибиться. В любом случае миф развеется: всем и всё станет очевидным, например, что «король голый» или наоборот — «какого фасона на нем ЕА» и что инвестиции в этот самый ЕА были оправданы.
1.3.1 Мистика. Неуловимый Enterprise Architecture example
Почему кнопка в гугл: «Enterprise Architecture example» не работает? Где примеры? Конкретные и подробные.
Даже не удалось найти вариантов заполнения под конкретное российское предприятие простенькой таблицы с именем «Zachman Framework» для моделирования архитектуры … (архитектуры чего? ЕА или ISA).
Попытки «Посмотреть на конкретный пример ЕА» все как один (два): или «купи проект по ЕА» или (самый дешевый) «пройдите наш платный курс, мы вам ТАМ покажем (и то «по очень большому секрету»)».
На улице ко мне также иногда подходят, «кастрюльки впаривать» и рассказывают примерно также грамотно (фактически готовые ЕА — консультанты) и такие же истории, как и с ЕА: «смотри — блестит, это очень круто, ты только купи». Сравниваем с устаревшими и новыми заклинаниями ЕА и ВРМ — от реинжиниринга, до цифровизации. Плюс обязательная фраза из типового скрипта продавцов BPM \ EA: «главное поймите — у вас же специфика! Вам подойдет только эксклюзив, нужна кастрюлька (ЕА) уникальная и неповторимая»:
Осознание преимуществ типового подхода, гласность и обмен практическим опытом (не мантрами), публикация описаний ЕА (BPM) — сокрушительный удар по алхимии. Однако ситуация пока — как на рисунке: «уникальность бизнеса», «особая тропа по пути цифровой трансформации», NDA – залог провала проектов ЕА, неэффективности и вечного изобретения велосипедов.
Где посмотреть полноформатную целостную ЕА на каком-либо фреймворке или без него? Хоть на одном А4 по Захману или пухлую стопку книг по Шеккерману? Хоть ЕА булочной, хоть ЕА «народного достояния» (газпрома и etc.). Хоть «одним глазком»?
1.3.2 Разоблачение портных короля
Есть простые способы или доказать, что «А король-то голый!» или показать что «все хорошо! Наряды короля правильные, а ЕА — это вам совсем не алхимия, а настоящая наука". Для этого нужно просто начать публиковать эти самые описания ЕА.
С чего начать борьбу с алхимией? Можно начать с «самых маленьких» — малых предприятий. У них ЕА должна быть попроще, чем у корпоратов. Вернемся к вопросу, что такое предприятие в контексте ЕА?
Это и предприятия малого бизнеса и холдинги, это даже домохозяйства и само государство. Почему консалтеров и системных интеграторов интересуют только «сложные ЕА», холдинги, промышленные кластеры, крупный бизнес? Ведь лучше начинать с простых примеров.
Интерес исключительно к корпоратам обусловлен лишь тем, что они — «богатое буратино» и поэтому проект «описание ЕА» измеряется «круглыми суммами». Но подходы к описанию этой самой ЕА, ровно такие же, как и к описанию «ЕА домохозяйства».
Почему бы каждому «архитектору», жонглирующему понятиями ЕА, не составить архитектуру своего собственного домохозяйства? Почему никто не описывает ЕА бутика, булочной, детского сада?
Второй подход. Почему интеграторы и консалтеры с радостью описывают архитектуру других, «убедительно доказывая», что «это конкурентное преимущество» и т.п., но вот свою архитектуру (своей компании) не только не публикуют, но и не описывают.
Или у компаний консалтеров нет ЕА? Каким NDA они оправдываются?
Нужно ввести правило: «хочешь описывать ЕА других» — «начни с себя», вначале «опиши себя» и опубликуй свою ЕА. Это хоть что-то скажет как о самом предмете исследования (описание ЕА), так и компетенциях консалтера в этом предмете. Вывод: описание ЕА стороннего предприятия – нужно лицензировать, без лицензии можно делать описание ЕА только своего предприятия.
Я бы распространил это правило на публикацию книг по ЕА, где в предисловии будет обязательная ссылка url на полноформатное описание конкретного ЕА.
Третье. Гос- компании. Издать указ или постановление: все компании, где есть хоть копейка участия в капитале со стороны гос-структуры (т.е. компания с гос-участием) должны опубликовать свою ЕА. На какой методологии будет построено описание ЕА – не важно, можно выбрать любую известную Best Practice (или их ограничить перечнем) или разработать собственную.
Имеются возражения: «ЕА — это же IP. Кто же будет задаром такое раздавать?». Имеется ввиду Intellectual Property, интеллектуальная собственность, некая secret success story.
Посмотрим на этот самый «IP» — со стороны нас, обычных граждан — налогоплательщиков. Одна компания разработала EA для госкомпании №1. Мы (налогоплательщики) заплатили. Далее эта же или другая компания разработала для госкомпании №2 тоже EA. Причем, возможно, точно такую же. Мы (народ) снова заплатили.
Далее снова для госкомпании №3 сделали такую же ЕА, и нас (т.к. средства из бюджета) снова обобрали.
Нужна нам «такая IP»? Если за одно и то же (одну и ту же EA) мы платим свои же деньги, бюджетные, которые из нашего же кармана?
Тем самым не только народ обирают, но и ВВП накручивают: поставляя «одного и того же» и беря за «разработку» (читай повторное использование) сполна «как положено» и «улучшая» статистику (выполненные объемы).
Я про унификацию, тиражирование, гласность (прозрачность, публикацию не только факта закупки, но и результата), повторное использование (заимствование), эффективное освоение ранее уплаченных бюджетных средств (в том числе, моих), оптимизацию НАРОДНЫХ инвестиций.
Четвертое. Для коммерческих компаний, правительство (государство) может объявить конкурс на более «правильную ЕА», параллельно создавая «общий репозитарий ЕА». Или «сделать проще», также как для гос-компаний законом обязать (как в «Третье»): сдал бухгалтерский отчет, приложи еще и свою ЕА.
Хорошим примером популяризации открытого обсуждения примеров ЕА служит аналог общенационального конкурса «BPM — проект года»: bpmaward.ru
Чем общенациональный конкурс «ЕА — проект года», хуже «BPM — проект года»? А может быть это вообще одно и то же?
Пятое. Читающий эти строки «счастливый обладать свеженькой ЕА» может задуматься: консалтеры сделали моему предприятию ЕА, хорошо бы проверить: это точно ЕА? Они качественно выполнили работу? Я не переплатил?
Отбросив предрассудки про «конкурентные преимущества не публикации ЕА», такой обладатель ЕА решится опубликовать описание этой ЕА с вопросом: это вообще ЕА? Какие ошибки допущены при ее составлении? Сколько такой проект должен был стоить (красная цена проекту)?
Не удивлюсь, что после публикации «крутой ЕА», естественно, за «астрономическую цену» кто-то воскликнет, браво: это же «Квадрат Малевича, только особый «ценитель» может увидеть в этой мазне очертания архитектуры, да еще и предприятия».
Шестое. Хорошо бы, чтобы были установлены простые правила для книжек про ЕА, описаний новых методологий и фреймворков: наличие комплексного примера хотя бы небольшого предприятия.
Помните, была книга: Джордейн Р. — Справочник программиста. В нем вначале было сказано «что сделать», а потом подробно показаны три варианта решения: на верхнем уровне (бейсик), среднем и низком. Что-то подобное хотелось бы для EA найти: пример одного предприятия в реализации по нескольким методологиям \ фреймворкам ЕА!
1.3.3 Итого, Open EA
После публикаций конкретных ЕА (реальных компаний), мы будем наблюдать полную кашу из представлений об ЕА (хотелось бы ошибиться). Почему получится каша? Потому, что в описаниях будет «кто в лес, кто по дрова», т.к. в основе таких описаний — лежит пока еще алхимия, а не инженерия.
«Апробация» подходов есть лишь в воображении самих архитекторов, по завершению очередного проекта ЕА, наклеивающих очередную звездочку на свой картонный framework. Объективного подтверждения до сих пор нет (не встречал).
Напоминаю, что речь идет в первую очередь об описании ЕА, а не ИТ-архитектуры, и под «описанием» понимается не рекламная продукция (презентации). Хотя творчество Solution \ System (SA) и Infrastructure (IA) архитекторов тоже интересно было бы лицезреть в открытом доступе (полноформатные примеры, а не отрывки).
Архитектурная каша новоиспеченных архитекторов или вовсе «убежит» или распределится по «тарелочкам» (направлениям) «ИТ-архитектура» (ИТ-тарелка, т.е. SA, IA и др.), «бизнес-архитектура» и т.д. Тогда будет ясно: мухи отдельно, котлеты отдельно.
Будет наведен элементарный порядок, отброшена маркетинговая ересь, прояснен главный вопрос — что останется на листе с заголовком «Архитектура предприятия», т.е. «просто Enterprise Architecture», которую рисует не кто иной, как Enterprise Architect.
Любое обсуждение ЕА, как и любой другой архитектуры, начнется со сравнения других архитектур, также опубликованных, т.е. со сравнительного анализа: как самих архитектур, так и соотнесения конкретного предприятия (как и в случае здания, процессора) к определенному типу (стилю) архитектуры (микроархитектуры).
Уверен, что при массовых публикациях ЕА частично будет предпринят маневр типа «финт ушами», например, «на скорую руку» заполнение 30 клеток таблицы Захмана с последующим утверждением: «вот это и есть ВСЯ наша ЕА»! Но подобное гипер-упрощение просто покажет уровень компетенций «местных архитекторов».
Публикации ЕА вскроют важную деталь: будет понятно, в каких случаях, имели место целенаправленные паранаучные измышления консалтеров в целях «подзаработать на алхимии», а в каких — добросовестные заблуждения. Первые будут менее охотно печатать свои «шедевры» по ЕА (и советовать своим заказчикам не делать этого).
Возможно, когда-нибудь современные подходы к построению архитектуры предприятия и назовут «древняя наука по архитектуре предприятия» (алхимию называют же «древней химией»), но пока эта современная алхимия переживает свой «золотой век». Нас и ранее предупреждали об этом, например:
"Ажиотажная мода «на архитектуру» может привести к тому, что необходимый для ИТ подход ухнет на пару лет во тьму псевдонаучных статей." www.osp.ru/os/2006/03/1156580
Кромешная тьма над ЕА не проходит десятилетиями и даже сегодня не видно прояснения:
2 Критика Enterprise Architecture
2.1 Критика ЕА из wiki
Критики подходов к описанию ЕА не много, думаю потому, что это настолько размытое понятие, что не совсем понятно, что критиковать.
Тем не менее, критика есть, например, ЕА Criticism
— Ivar Jacobson: Большинство инициатив EA не удалось. Я предполагаю, что более 90 % никогда не приводили к чему-либо полезному »;
— Erasmus University Rotterdam IDS Scheer: две трети проектов ЕА не смогли улучшить «выравнивание» бизнеса и ИТ.
«Business and IT alignment» — слов-то каких напридумывали. Термин ввели, видимо, чтобы хоть как то «оправдать» внедрение дорогостоящих ИТ-систем, которые не обеспечивают адекватную (точнее хоть какую-нибудь) отдачу от инвестиций в ИТ: типа причина — в невежестве бизнеса, который сильно «отстает от передового ИТ» (т.е. очень дорогого ИТ).
Сами Автоматизаторы — «белые и пушистые», но вот «темный» бизнес не понял их «глубокого замысла», поэтому и неудачи на проектах ЕА (про неудачи также не принято рассказывать).
Иногда ЕА используется (замаскировано) — в качестве «мостика» — как желание CIO «порулить бизнесом» или хотя бы стоять на капитанском мостике на равных, а не представить ИТ – лишь как одно из обеспечивающих подразделений компании;
— Stanley B. Gaver: федеральная ЕА-программа в целом потерпела неудачу.
В пользу доводов Гавера можно сказать, что если что-то подобное (FEA \ FEAF или другие ЕА) действительно сработало бы и USA также, как и ARPANET передали бы технологию мировому сообществу, то сегодня мы имели бы новый TCP\IP на бизнес-уровне, т.е. «business net». Появились бы хабы бизнеса, коммутаторы, бизнес-протоколы, абсолютная стандартизация, стандартный «стек бизнеса», а в магазинах электроники продавались бы «бизнес-маршрутизаторы» и т.п.
Фрагмент из wiki уже по framework en.wikipedia.org/wiki/Enterprise_architecture_framework
- Исторический анализ публикаций EA показывает, что «EA frameworks» — это «не что иное, как типичные управленческие причуды, агрессивно продвигаемые консалтинговыми компаниями и гуру».
- Про управленческие причуды: en.wikipedia.org/wiki/Management_fad
- Исследования показывают, что «EA frameworks» кажутся теоретизированными и невозможными для реализации.
- Вивек Кундра, федеральный директор по информационным технологиям США: «EA frameworks» — «хуже, чем бесполезно».
- Джейсон Блумберг сообщает, что «EA frameworks» попусту тратят время архитекторов, вместо того чтобы решать реальные проблемы. «EA frameworks» — это кокаин для руководителей — они дают им огромный раш (кайф, ажиотаж, устремление), а затем они переходят к следующему frameworks».
2.2 Laws of #BPM (Business Process Management)
improving-bpm-systems.blogspot.ru/2015/07/laws-of-bpm-business-process-management.html
Родственные направления алхимии местами переплетаются. Отличить где кончается BPM и начинается ЕА – очень сложно. Поэтому и мифы у них идентичные, алхимия же.
Закон 1
Каждый поставщик BPM (ЕА), каждый консультант BPM (ЕА), каждый «свод знаний» BPM (ЕА) (“body-of-knowledge”), каждая методология и фреймворк, и каждый клиент BPM (ЕА) понимают BPM (ЕА) по-разному. Это отличительная особенность любой алхимии.
Закон 7
Правильно сделанный BPM — это 50% Enterprise Architecture (EA).
Видимо верно и наоборот: Правильно сделанная ЕА – это 50% BPM.
Вообще странно, что не учитывает ВРМ по сравнению с ЕА? Что можно рассматривать ВРМ без оргштатной структуры, без входов и выходов процессов?
Любая «динамика» в ЕА – это уже и есть процесс, т.е. ВРМ. А в ВРМ задают и описывают всё связанное с процессом. Фактически любой жизненный цикл любого объекта или артефакта – это связь его состояний через процессы, т.е. направления переходов (из одного состояния в другое).
Особенно сложно для понимания являются встречающие в одном месте: Управление «архитектурой предприятия» и управление бизнес-процессами (BPM) предприятия. Типа «управление архитектурой» и «управление процессами», при этом «архитектура данных» и другие «суб — архитектуры» могут произвольно упаковываться сразу в оба указанных контейнера.
Закон 8
Проблемы BPM (ЕА) возникают из-за того, что его теория не завершена и не подтверждена. Другими словами если это не – алхимия, то и не научная или инженерная дисциплина. Интересно, а что тогда?
Самый точный вывод указан в Закон 14:
Corollary 1 BPM (ЕА) community is a group of alchemists.
Привел лишь часть примеров (законов), остальные смотрим по ссылке на блог А. Самарина.
2.3 Enterprise Architecture is… DEAD!
Часто на неудачных проектах по BPM и ЕА делается вывод: A fool with a tool is still a fool.
Enterprise Architecture: Don't Be a Fool with a Tool
www.forbes.com/sites/jasonbloomberg/2014/08/07/enterprise-architecture-dont-be-a-fool-with-a-tool
«Дурак с инструментом все еще дурак» — слова мудрости в ИТ. Тем самым делается намек, что если у вас не получился проект по нашим «гениальным» ТОГАФ и табличкам Захмана и еще 50+ подобных «Best Practice», то не нужно про это рассказывать – т.е. выставлять себя и своего напарника – дураком (вендора, интегратора, консалтера, заказчика). Вот такая удобная «народная мудрость». Удобная, исключительно для алхимиков и их жертв.
Тот же автор (Jason Bloomberg) утверждает, что
за годы, прошедшие с момента основания Джоном Захманом нового направления «архитектура предприятия» (ЕА) в статье 1987 года в журнале «IBM Systems Journal», EA достигла удивительно ничтожного уровня развития (успеха).
… Истории заброшенных или неудачных инициатив EA значительно превосходят реальные примеры проектов EA, имеющих ценность для бизнеса.
Is Enterprise Architecture Completely Broken?
«К сожалению, EA часто является синонимом практики документирования взглядов одного человека на ИТ их компании, — сетует Гриси.
Подчеркиваю: именно на ИТ, именно на документирование и именно лишь субъективизм архитектора. Такой подход вообще должен был погибнуть изначально.
Однако, второй слайд: Enterprise Architecture is… DEAD! — слишком оптимистичен.
www.opengroup.org/public/member/proceedings/Johannesburg-2015-03/Presentations/The%20State%20of%20Enterprise%20Architecture%20Globally%20-%20James%20Thomas.pdf
По – хорошему, «ЕА – как алхимии» — давно должен был настать конец, но сегодня это очень хороший сегмент бизнеса, где главное не результат (где он?), а «сам процесс» (классический лозунг ВРМ). ИТ-Волшебники с биркой «ЕА-консалтинг», практически из ничего научились добывать золото: высокодоходный бизнес по консалтингу ЕА. Классическим алхимикам до такого «мастерства» было далеко.
Поэтому в статье и использован негативный окрас к подобному консалтингу: чаще всего пришлые профессиональные архитекторы знают (подозревают) о лженаучности применяемых подходов, но, подобно фокусникам, «выполняют свою работу» и в тайне держат статистику неуспешности и сами «фокусы»: не классические фреймворки (они публикуются), сколько искусство манипулирования ими и сознанием заказчика.
Следовательно, можно дать еще одно определение, EA — это в основе своей современный подход к алхимии, санкционирующий и методически гарантирующий получение дохода практически из «ничего», путем употребления старинных и модернизированных заклинаний ЕА & BPM, магических framework (прошлого века и совсем свежих), абстрактных формулировок, типа:
«Архитектура предприятия устанавливает путь к достижению миссии организации благодаря оптимальному функционированию ее ключевых бизнес-процессов внутри эффективного ИТ- окружения.” Jaab Schekkerman, Institute For Enterprise Architecture Development (IFEAD).
Если ране это было (старинные заклинания): реинжиниринг бизнес-процессов и оптимизация затрат, снижение затрат и рисков, то сейчас это «усовершенствованные заклинания»: адекватный ответ меняющимся вызовам рынка, реализация бизнес-стратегии через цифровую трансформацию, цифровизация бизнеса и предприятия, выравнивание бизнеса и ИТ и другие мантры.
2.4 Enterprise Architecture Frameworks: The Fad of the Century
The Fad of the Century
Один из немногих примеров откровенной и «колкой» критики ЕА:
«… все популярные EA фреймворки и их концептуальные предшественники являются очевидными маркетинг-ориентированными управленческими трюками (фантазиями) без предъявления примеров успешной реализации. Хотя многочисленные маркетинговые публикации последовательно позиционировали EA фреймворки — как «лучшие практики», научно обоснованные исследования последовательно демонстрировали противоположные выводы.
Различные консультанты и гуру делают свои деньги продажей того, что можно эффективно продать, независимо от того, работает оно или нет.
Например, Джон Захман, «отец» EA, который ранее продвигал ошибочную методологию BSP во время своей прежней 26-летней маркетинговой карьеры в IBM, недавно приобрел Институт сертификации федеральной корпоративной архитектуры (FEAC) и сейчас активно продает сертификаты и тренинги в FEAF, EA фреймворк которой в значительной степени ответственен за миллиард долларов потраченных денег налогоплательщиков, вложенных в программу FEA.
Члены Института FEAC по-прежнему продвигают программы сертификации в тех же структурах EA, которые представляют собой ошибочные «лучшие практики». Безумие здесь заключается в том, что сообщество экспертов EA по-прежнему не признает EA фреймворки в качестве еще одной управленческой уловки (management fad), и многие специалисты EA все еще хотят получить сертификацию по некоторым из этих EA фреймворков.
Тот факт, что консультанты могут продавать одни и те же наихудшие методы под названием «лучшие практики» на протяжении нескольких десятилетий, даже когда достоверная информация является общедоступной, наглядно демонстрирует неограниченную силу бесконечных маркетинговых обещаний и полное бессилие здравого смысла, основанного на доказательствах. Эта ситуация наглядно иллюстрирует другое печально известное высказывание: «ложь, рассказанная тысячу раз, становится истиной».
… нет практических способов заполнения 30 или даже 15 ячеек Zachman Framework. … Практических способов разработки всех или даже половины документов, рекомендованных TOGAF, нет…»
Management fad — управленческая концепция, которая имеет красивое название и предлагает новый путь повышения эффективности; обычно разрабатывается каким-либо теоретиком управления или консалтинговой компанией, затем становится популярной в широких кругах теоретиков и практиков менеджмента, вызывает большое количество исследований, публикаций, семинаров и т. п.,
после чего постепенно ее популярность падает, и она уступает место новым модным концепциям; поскольку создание успешной популярной концепции является очень выгодным бизнесом для консультантов и теоретиков, последние уделяют особое внимание ее эффектной формулировке и продвижению, иногда при этом внешняя сторона сильно перевешивает реальное содержание.
slovar-vocab.com/english-russian/new-management-work-economics-vocab/management-fad-1127771.html
Согласен со Святославом Котусевым: ЕА – это афера века. Конечно, критиковать ЕА и «кидать камни» в ее фреймворки — проще, чем предложить что-то более конструктивное, но кто-то должен сказать, что «король-то голый».
Восхваление прозрачного «платья короля» и поклонение алхимии — это еще более простой и для многих удобный путь. Чтобы построить что-то новое, нужно «расчистить место», разоблачить мифы прежних подходов.
От Святослава досталось и «бедному» Тогафу:
The critical scrutiny of TOGAF
Выдержки:
"… хочу заметить, что TOGAF появился в 1995 году, и его основные элементы, например ADM, с тех пор остаются практически неизменными. Как может быть, что «лучшая практика», разработанная более 20 лет назад, все еще не может быть реализована нигде …
… TOGAF основывается на TAFIM, но TAFIM, был подтвержден как неудачный, поскольку проекты EA требовали огромных инвестиций времени и денег, в результате архитектуры часто устаревали еще до завершения проекта, а бизнес-заказчики обычно не могли их понять. Если TOGAF основан на TAFIM, и TAFIM оказался неудачным, то как TOGAF может основываться на передовой практике?
В свете этих наблюдений становится ясно, что TOGAF не отражает реальной практики … В то же время обещания The Open Group о том, что TOGAF «обеспечивает наилучшую практику можно рассматривать только как типичные бессмысленные маркетинговые заявления, направленные на продвижение продаж …
Например, в настоящее время в мире насчитывается более 52 тысяч сертифицированных по TOGAF человек по всему миру. Это означает, что Open Group заработала не менее 23 миллионов долларов только на сертификатах TOGAF.
Если вы добавите различные тренинги, курсы, книги, конференции, консультации и другие прибыльные услуги TOGAF, предоставляемые The Open Group, то это число, вероятно, будет намного больше. Если бы вы были The Open Group, разве вы не утверждали бы, что TOGAF представляет лучшую практику?
Многочисленные гуру, тренеры, инструкторы, эксперты, консультанты, центры сертификации и т. д. связывают свою судьбу с «продажей» TOGAF. Неудивительно, что все они заинтересованы в продвижении TOGAF и избегают любую критику по отношению к нему.
… ситуация выглядит безнадежной, поскольку, вероятно, ни один из влиятельных игроков на рынке EA не мотивирован предложить какие-либо альтернативы TOGAF: если люди охотно платят за TOGAF, то зачем изобретать что-то еще?
Третий фактор — позорная (или даже криминальная) инертность исследовательского сообщества EA, к которому я отношусь. К сожалению, исследователи EA обычно не дают объективного анализа ситуации в дисциплине EA … В этой атмосфере невежества многочисленные мифы, легенды и суеверия, связанные с ЕА, распространяются очень быстро … академические исследователи EA, как правило, одержимы производством «научных» теорий вместо ответов на реальные практические вопросы.
Тот факт, что TOGAF теперь преподается в престижном университете наглядно демонстрирует капитуляцию армии академиков перед маркетинговыми агрессорами."
Точно в цель. Направление «Бизнес-информатика» в отечественных вузах со специализацией на ЕА фактически превратилась в пособие по алхимии. Итак, наука в стране в загоне, а тут еще и алхимики окопались «в тылу».
Из Enterprise architecture is not TOGAF
" … сообщество EA должно проявить трезвый реалистичный взгляд на существующую литературу EA, критически пересмотреть и переосмыслить свои идеалистические идеи, которые в настоящее время очень далеки от реальной практики EA в организациях.
Основанные на фактических данных новые источники информации об EA крайне необходимы в качестве замены в основном бесполезных, но активно продвигаемых EA фреймворков."
Почитателям ТОГАФ — предлагаю принять участие в конкурсе на описание «household architecture» (третий параграф настоящей статьи).
2.5 Мягкая критика
В интернете уже давно и много «мягкой» критики (см. гугл) современных и совсем не современных подходов к ЕА, только «точка кипения» еще не наступила, возможно, потому что «очень многие оказались в деле \ в доле».
Много из того, что выше было сказано, повторяется в блогах западных критиков, правда в смягчённых формулировках, возможно потому, что свой хлеб они зарабатывают на этом самом ЕА.
filipebartolomeu.weebly.com/blog/tackling-enterprise-architecture-criticism
searchcio.techtarget.com/blog/TotalCIO/Two-IT-gurus-face-off-on-value-of-enterprise-architecture-frameworks
Странно, что подобной критики в рунете не нашел. Это говорит или о том, что в отличие от западного опыта, в России большинство проектов ЕА — успешные (на удивление всем нам и зависть буржуям) или об уровне зрелости отечественного образования по ЕА. Склоняюсь ко второму варианту.
Если мы говорим не об алхимии, то должен быть взят на вооружение принцип: «несомненнымъ является существование только нашего мыслящаго „я", существование же всего остального должно быть подвергнуто сомнению».
3 Конкурс на описание «household architecture»
Предлагаю начинающим и маститым архитекторам любых ЕА-конфессий составить описание архитектуры своего домохозяйства: «household architecture». Это будет лучшее подтверждение, что «Enterprise architecture» в их понимании имеет право на существование.
Надеюсь, что архитекторы согласятся, что домохозяйство имеет архитектуру и, что «household architecture» (HA) может быть представлена на базе известных подходов к описанию ЕА. Также надеюсь, что при описании своей HA, никому не понадобится NDA для супруга.
Условия участия простые: архитекторы подробно показывают свою «household architecture», рассказывают, как они ее строили и дают ссылки на используемый framework. Впрочем, можно привести любую другую «простую архитектуру» «простого предприятия»: детского сада, киоска «мороженное» и т.п.
Будет еще лучше, если:
А) архитекторы будут приводить несколько архитектур НА, указывая на их архитектурные отличия;
Б) описание одной и той же НА покажут на разных подходах, методологиях описания, фреймворках.
Ссылки на описания НА даем в комментариях к этой или к следующей главе (статье). В ней, в свою очередь, опубликую свое видение НА. Голосованием определим самую «правильную», наиболее «архитектурную» архитектуру домохозяйства. Оповестите знакомых архитекторов (включая ЕА, SA, IA и других хА), дайте им возможность внести посильный вклад в развитие ЕА \ НА. Месяца нам — архитекторам на это хватит? Задача то не архи-сложная.
Итак, писатели статей про ЕА, особенно живущие на хабре, – присылайте свои НА \ ЕА. Скромничать не нужно: думайте, рисуйте, «архитектурьте». Зачем рассуждать о сложном ЕА, давайте поговорим о простом НА.
'Non-alchemysts' aller Lander, vereinigt euch!
Представьте, какая досада охватит многих алхимиков, когда:
- простым языком будет показано, что такое ЕА и подтверждено конкретными примерами в понятных методичках;
- придет понимание, что составлять описание архитектуры могут простые смертные без помощи магии алхимиков;
- выяснится, что в большинстве случаев вообще не нужно изобретать велосипед, а нужно лишь заимствовать стандартную (типовую) архитектуру. А может даже целиком проектное решение, отвечающее нужной архитектуре.
Ваш, bipiem
Комментарии (80)
leossnet
25.12.2017 10:10Исходя из концепции, что экономика – это ремесло, подчиняющееся четким требованиям по достижению результата как любая техническая (кибернетическая) система, можно сделать следующее определение архитектуры предприятия:
Архитектура предприятия представляет собой логическую модель (модель управления) обмена информацией (управляющими воздействиями) о предприятии (объекте управления) между начальниками различных уровней (субъектами управления).
На практике существует всего две модели управления:
— иерархическая, описываемая структурой данных «дерево»
— сетевая, описываемая структурой данных «граф»
В реальной жизни обычно наблюдается смешение этих моделей управления, однако с явным доминированием одной из двух. Выбор же модели управления полностью определяется личными предпочтениями руководителя предприятия.
Существует очень простой способ определить принадлежность архитектуры конкретного предприятия к одной из этих двух моделей: при согласии большинства руководителей предприятия с утверждением, что на их предприятии практикуется подход «я – начальник, ты – дурак», то можно говорить о иерархической модели, иначе на предприятии преобладает сетевая модель управления.
Сразу оговорюсь, что обе модели управления имеют право на существование, так как имеют свои сильные и слабые стороны. Иерархическая модель более устойчива, но при этом слабо восприимчива к инновациям, сетевая же модель достаточно гибка, но при этом очень сильно зависима от уровня квалификации руководителей и ключевых сотрудников.
Что же касается формализованного описания объекта управления, то для бизнеса имеет значение не то, как точно и детально зафиксирована в статике система управления предприятия, существовавшая в прошлом (ведь на описание архитектуры нужно время), а насколько точно одни начальники (субъекты управления) в состоянии своевременно и точно доводить до других начальников информацию (управляющие воздействия) о руководимых ими подразделениях (объектах управления) относительно настоящих и будущих задач.
По этой причине единственным способом повышения эффективности бизнеса в рамках любой модели управления является повышение точности управляющих воздействий. Эта мера направлена на уменьшение эффекта «глухого телефончика», при котором из-за искаженной информации приходится постоянно все уточнять и переделывать, что ведет к удлинению сроков и росту издержек.
В иерархических системах повысить точность управляющих воздействий можно с помощью повышения качества регламентации документооборота, а в сетевых системах – применением трекеров задач (мой любимый трекер YouTrack).
Что же касается бизнеса различных консультантов, то здесь остается только привести слова классика – «ах, обмануть меня не трудно, я сам обманываться рад». Для большинства начальников мыслительная деятельность достаточно утомительна, поэтому все они хотят «большую красную кнопку», которая бы решала за них возникающие на предприятии проблемы. Тем более, что за эту «большую красную кнопку» нужно платить не из своего кармана, а кармана собственника бизнеса. На этом и делают свой немаленький гешефт различные консультанты.
bipiem Автор
25.12.2017 11:24Вы рассматриваете лишь часть ЕА, назовем ее архитектура системы управления (СУ) предприятием. Можно назвать — общая модель управления предприятием (чтобы не путать с частной, с конкретной).
Есть много разных подходов, указав на «две модели управления» иерархическая и сетевая — Вы погорячились.
Одно из направлений — «50 оттенков управления компанией» (50 оттенков бирюзы), это где рассказывают: как хорошо компании быть бирюзовой (красная, янтарная, оранжевая, зеленая и бирюзовая).
www.mann-ivanov-ferber.ru/teal-organization
habrahabr.ru/post/323532
Понятно, что 5 — это только основные цвета управления, а в реальности спектр больше: условно 50 и не цветного, а скорее серого.
Есть подходы к управлению через жесткую формализацию — регламентацию, а есть компании, где все многостраничные регламенты компании — это «филькина грамота» и управление строится на «ручном приводе». Есть отдельно модель управления (архитектура, архитектурная модель), где сплочённой команде требуется минимум формальностей, и они практически понимаю друг друга с полуслова. В них вместо конкуренции — взаимопомощь, все открыто и добросовестно по отношению к «команде» и т.п.
Есть другие направления описания модели управления компании, например, дивизионная, матричная, проектная (нигде не видел).
У Вас в «иерархической» — смешение: из одной «оперы» — это дивизионная, из «другой» (50 оттенков) — это тоталитарное управление. Однако четкая иерархия не обязательно основана на тоталитаризме — деспотизме: «я – начальник, ты – дурак».
Да, все это архитектурные особенности предприятия, точнее: архитектуры системы управления предприятием. И эти суб-архитектуры также напрямую определяют (влияют на) общую архитектуру. С этим согласен.
Важно, чтобы при описании архитектуры предприятия — была показана ее суб-архитектура «системы управления предприятием».
Однако классический подход (алхимиков) к описанию ЕА не замечает этого. Про суб-архитектуры СУ в рамках общего описания ЕА — это отдельное направление (методологическое, фреймворксное) и не менее важное, чем ИТ-архитектура предприятия.leossnet
25.12.2017 12:14Для меня принципиальным моментом при классификации систем управления является маршрут прохождения информации от инициатора какого-либо действия до конечного исполнителя, а также способ получения обратной связи для возможности оперативного вмешательства в деятельность предприятия.
Поэтому и выбраны всего лишь две принципиальные структуры данных, у которых алгоритмы обхода узлов структуры принципиально отличаются – дерево и граф. В дереве для перехода к любому узлу необходимо вначале подняться до общего родительского узла, а лишь затем спуститься вниз до адресата. Для графа же можно построить прямой маршрут до адресата буквально в один шаг.
С этой точки зрения формулировка «я – начальник, ты – дурак» означает всего лишь отсутствие обратной связи при взаимодействии двух соседних узлов — либо это односторонняя трансляция информации от родительского к дочернему узлу, либо в обратном направлении.
Относительно цветов и оттенков следует сказать, что автоматизировать можно только количественные параметры. Цветовая же схема не подлежит автоматизации, пока не будет детализирована до (кибернетических) процессов, алгоритмов и структур данных.
Что же касается самого понятия предприятия, то для меня это и есть управляющая надстройка над реальными физическими процессами – техническими или социальными. Любой бизнес легко можно представить состоящим только из одной управляющей надстройки, в которой управление физическими и социальными процессами делегировано другим организациями на основании коммерческих договоров. В свою очередь сами по себе технические и социальные процессы не могут представлять из себя предприятие, пока их кто-то не приберет к своим рукам.
Поэтому с точки зрения архитектуры предприятия любой технический или социальный процесс представляет собой всего лишь черный ящик со своим набором входов и выходов, а также интерфейсом для подключения управляющих воздействий для предприятия.
Перечисленные же примеры систем управления (дивизиональная, матричная, проектная) представляют собой лишь комбинации базовых систем управления:
— дивизиональная – сетевая на уровне компании и иерархическая на уровне дивизиона;
— матричная – иерархическая с двумя древовидными контурами управления, когда любой объект управления имеет двойную подчиненность (распространена в промышленности в управлении производственными цехами);
— проектная – чисто сетевая структура управления (временные или постоянные рабочие группы).bipiem Автор
25.12.2017 12:59Относительно цветов и оттенков следует сказать
Принцип градации «красный — бирюзовый» не требует автоматизации оттенков, во всяком случае, напрямую. Это «философия», «разные архитектуры» — их затруднительно взять и запрограммировать в исполняемом коде. Они скорее программируются в сознании.
самого понятия предприятия, то для меня это и есть управляющая надстройка
Почему только «управляющая надстройка»? А все остальное?
Кроме того, у Вас так часто встречается «управление процессами», то уже действительно непонятно про какой раздел алхимии идет речь: то ли про «ЕА», то ли уже о «ВРМ». См. п. 2.2 Laws of #BPM (Business Process Management)
Сделанные вами выводы где-то еще показаны? Т.е. есть ссылки примерно на то же самое, что Вы говорите, но словами другого автора? Не могу понять, мне нужен или «другой взгляд» на то же самое или детализация подхода.
Поэтому с точки зрения архитектуры предприятия любой технический или социальный процесс представляет собой всего лишь черный ящик …
Как Ваш принцип ложится на простые примеры, например, «Архитектура домохозяйства». Желательно с конкретным примером.
leossnet
25.12.2017 13:40Ссылки на источники информации представить не могу, так как описываю собственный практический опыт работы в крупной многоотраслевой компании в качестве экономиста по нестандартным вопросам стратегических и инфраструктурных направлений.
Наиболее значимые результаты своего опыта начал выкладывать на сайт www.leossnet.ru.
Что же касается домохозяйств, то можно привести следующие примеры для обеих моделей:
1. Иерархическая модель. Муж (центр доходов и объект управления) зарабатывает деньги и отдает жене (субъект управления). Жена (центр затрат и субъект управления) оплачивает текущие расходы (еду и коммуналку) и согласовывает/навязывает мужу покупку дорогостоящих покупок (инвестиции). Воспитанием детей (объектов управления) занимается жена (субъект управления), иногда привлекая мужа к наказаниям детей за проступки (корректирующее воздействие). Преимущества – устойчивость семейных отношений, слабые стороны – одностороннее воспитание детей.
2. Сетевая модель. Муж и жена зарабатывают деньги (центры прибыли и субъекты правления) и тратят их на текущие расходы по собственному усмотрению в рамках согласованных лимитов. Для дорогостоящих покупок договариваются каждый раз по схеме финансирования (накопить или взять кредит) и своей доли участия. Воспитанием детей (объектов управления) каждый из родителей занимается в рамках своей специализации (муж – логика и железки, жена – чувства и тряпки). При возникновении проблем в воспитании детей пытаются разобраться в проблеме и внести коррективы в формат общения в детьми (модифицировать систему управляющих воздействий и механизм обратной связи). Преимущества – гармоничное развитие детей, слабые стороны – риски распада семьи при конфликте интересов супругов.
Приведенные модели являются частными случаями и полностью определяются личностными качествами супругов.bipiem Автор
25.12.2017 14:13Мне показалось, что в Вашем подходе слишком большое внимание уделено «семейности». Домохозяйство — это скорее экономическая сущность. Воспитание детей, семейные отношения и т.п. — это не главная атрибутика «household architecture» (НА).
Кроме того, ЕА и НA — это, прежде всего, все-таки схемы (реже таблицы).
Какую конкретную ссылку на указанном Вами ресурсе можно считать наиболее близкую по теме обсуждения?leossnet
25.12.2017 14:56Из концептуальных вещей следует смотреть страницу, содержащую ссылки на внешние ресурсы:
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/
Что же касается примеров домохозяйств, то их классификация приведена с точки зрения достижения результатов по самой значимой целевой функции, направленной на биологическое воспроизводство человеческой цивилизации – воспитанию детей, основного ресурса и источников по его получения – денежных средств, а также распределения ролей между членами семьи в рамках процесса семейной жизни.
Если же будут другие вводные, то можно выполнить другую классификацию. Только зачем? У человека самый дефицитный ресурс – это его время готовности головного мозга к интеллектуальной деятельности. Поэтому его рационально тратить на то, что реально способно изменить окружающую действительность. Если же появится реальная потребность у реального человека, то можно сделать что угодно при должной мотивации исполнителей.bipiem Автор
25.12.2017 15:43их классификация приведена с точки зрения достижения результатов по самой значимой целевой функции, направленной на биологическое воспроизводство человеческой цивилизации – воспитанию детей
К параграфу №3 статьи: Предлагаю поговорить о «выходах» домохозяйства, точнее «продуктовых» выходах. Какой по Вашему «Каталог продуктов и услуг» домохозяйства. В терминах «продуктов и услуг».
Например, продукт домохозяйства «второй ребенок» оценивается заказчиком (государством) в 250 тыс., другие тарифы на «продукты НА» приведены
posobie-expert.ru/regiony/detskie-posobiya-v-moskve
Какие иные продукты, кроме категории «детские» попадут в Каталог продуктов и услуг НА?
Вообще есть сомнения, по поводу «самой значимой целевой функции» — воспроизводство. Для НА, как экономической сущности — понятия «человеческой цивилизации» если и существуют, то не первичны.
Что должно для НА входить в его Scope & Vision?
Какой полный ролевой состав в НА (распределение ролей)?
System12
26.12.2017 13:04В контексте статьи ключевым ресурсом является ссылка на статью Олега Кольцова. Процессный подход с точки зрения кибернетики:
============
Лучше вместе с другой моей статейкой «ПРОЦЕССНЫЙ ЛАНДШАФТ И ОРГСТРУКТУРА» :))
process.mirtesen.ru/blog/43852778662/PROTSESSNYIY-LANDSHAFT-I-ORGSTRUKTURAbipiem Автор
26.12.2017 13:40Вопросы, как автору статей по процессам:
— Ваше мнение о проблеме, показанной в статье Enterprise Architecture vs алхимия предприятия. Ключевые мифы
— как сочетаются BPM и ЕА?
— где найти методичку, как составить реестр процессов компании?
Тему начал здесь: habrahabr.ru/post/343190
Термин «Владелец процесса» означает должностное лицо организации, на которое возложена ответственность за разработку, управление и поддержание в установленном состоянии руководимого им процесса.
Если это (что указано выше) относится к начальнику Х, но за результат этого процесса отвечает У, то владельцем будет все равно Х? Как тогда называть Y?
Может ли быть владельцем — тот, кто вообще не принимает никакого участие в процессе?
Может ли у процесса быть более одного владельца?
Понравился вывод — процессный ландшафт vs ИТ-ландшафт:
Еще одной проблемой определения процессного ландшафта является подмена целей при проведении автоматизации системы управления организацией. При этом цели улучшения и оптимизации системы управления подменяются целями проведения автоматизации ради автоматизации.
System12
26.12.2017 14:21Все лениво написать статейку по этим вопросам. Кратко:
1. Реальность слишком сложна для понимания и потому люди для ее понимания придумывают различные модели, представляющие собой упрощенный взгляд с какой-либо стороны. На мой скромный взгляд все модели равноправны, если они отражают характеристики реальности и потому желательно одновременно рассматривать несколько моделей, а не биться головой о пол молясь на единственно правильную.
2. Методички нет потому что реальность слишком сложна при простоте высшего процесса всего живого и организационного — «Выживание».
Реестр процессов появляется при декомпозиции этого процесса.
3. Вопрос двойного подчинения искусственен. Владелец процесса это субъект, определяемый из декомпозиции процесса более высокого уровня, а не назначаемый произвольно. Назначить можно только стрелочника.
4. Исходя из п.3 — не может.
5. Аналогично п.4.bipiem Автор
26.12.2017 15:37Может ли быть владельцем — тот, кто вообще не принимает никакого участие в процессе?
3. Вопрос двойного подчинения искусственен. Владелец процесса это субъект, определяемый из декомпозиции процесса более высокого уровня, а не назначаемый произвольно. Назначить можно только стрелочника.
4. Исходя из п.3 — не может.
Интересный вывод у Вас:
Значит тот, кто участвует в процессе больше всех, но ему совершенно наплевать на результаты процесса — это Владелец процесса.
Соответственно, этот «владелец» выстраивает процесс так, чтобы был нулевой результат (ему все равно), но главное — чтобы процесс был для него комфортным, т.е. главное процесс, а не результат!
А тот, кто является заинтересованным в результатах процесса и готов всячески бороться за результат процесса (правда «чужими руками»), — он вообще «никто» (и не участник и не владелец).
Странная логика.
Кроме того, не уловил основы для вывода «5. Аналогично п.4.».
В данном случае, все подразделения — активные участники процесса и все претендуют на звание «владелец». Нужно или считать их как «совладельцами» или по каким-то критериям определять «наиглавнейшего».
2. Методички нет потому что реальность слишком сложна при простоте высшего процесса всего живого и организационного — «Выживание».
Что-то мне это напоминает. Не алхимию ли?System12
26.12.2017 15:57Вы решили меня рассмешить? Или хотите заставить меня написать статейку о том, «Как все запущено?»
Владелец процесса это его субъект, сам процесс это объект его управления. Двухголовое животное это не жизнеспособный мутант. У любого объекта не может быть двух субъектов управления. Двоевластие нежизнеспособно.
Как говорили во времена СССР: «Слава КПСС» не человек, подразделения сами по себе ничего не хотят и хотеть не могут.
Я не виноват в том, что Вы путаетесь в функциях подразделений при матричной структуре, считая что в ней куча владельцев одного процесса.
А декомпозировать процесс выживания слвбо? Без алхимии, только на логике и здравом смысле?
Подсказываю на примере: чтобы выжить нужно найти источник пищи, воды, воздуха (на вершинах гор даже орлы не живут), жилище и далее по списку. Деятельность по поиску всего необходимого может называться процессами, являющихся подпроцессами основного процесса. :))bipiem Автор
26.12.2017 16:21Ваши доводы звучат как: «знаю, но не скажу». Я надеялся услышать: делай раз, делай два … и получишь список своих бизнес-процессов. Ну, хотя бы высокоуровневых.
А пока вижу только «что — то», что и теорией-то назвать сложно. Ссылок точно нет? Конкретных примеров по инвентаризации процессов компании?
Неужели такой очевидный и первостепенный вопрос — как составить список ключевых бизнес-процессов компании нигде не освещен с практических позиций.
Не нужно голой теории, нужна практическая методика.System12
26.12.2017 16:341. Вы знаете определение бизнес-процесса? Не лично понимаемое, а стандартное, принятое во всем мире?
2. Вообще-то списки есть, включены в ряд систем управления предприятиями, только они не всем подходят и их механическое перенесение зачастую ставит персонал в полный ступор.
3. А серьезных разработок декомпозиции процессов действительно нет. Слишком сложная и многовариантная задача.System12
26.12.2017 16:43Добавлю определений из одного словаря:
Архитектура
В моделировании процессов – целенаправленное определение места модели в общем фреймворке, описывающем весь бизнес через его составные части. Во избежание неоднозначности в качестве основы для архитектуры можно взять широко известный фреймворк, например предложенный Захманом или производный от него, такой как 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).
bipiem Автор
26.12.2017 17:291. Вы знаете определение бизнес-процесса? Не лично понимаемое, а стандартное, принятое во всем мире?
стандартное, принятое во всем мире??? Очень смешно. Этому посвятил аж три статьи:
Бизнес-процессы: Как все запущено и запутано. Глава Первая
Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»
Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
У алхимии не может быть «стандартного», стандарты появятся только на руинах алхимии.
Вообще-то списки есть
Кроме apqc что можете посоветовать?System12
26.12.2017 17:33Мне столько много букв не осилить. :))
Я поступил проще, сделав маленькую выписку из стандартов. :))
process.mirtesen.ru/blog/43779486784/Termin-%C2%ABProtsess%C2%BB-v-rossiyskih-i-mezhdunarodnyih-standartah
System12
27.12.2017 11:03Архитектура предприятия не алхимия, а ремесло! :))
Мой краткий алгоритм:
1. Берем устав предприятия и внимательно его читаем.
2. Находим высшую цель предприятия и заменяем существительное глаголом, например «Работаем для прибыли». Это доступный нам процесс высшего уровня.
3. Находим в уставе виды разрешенной деятельности и определяем какую из многоперечисленных реально выполняем.
Аналогично заменяем существительное на глагол, полученную деятельность условно говоря получая процесс «Производство продукции». Полученную деятельность рассматриваем как один из подпроцессов второго уровня.
4. Два других подпроцесса идут автоматом: «Управление» и «Обеспечение ресурсами»
5. Процесс производства наиболее просто декомпозировать на основе применения старого сетевого графика, рассматривая стрелочки на нем как его подпроцессы.
6. Анализируем требуемые ресурсы, начиная с инфраструктуры.
7 Из анализа потребностей в ресурсах получаем требуемые процессы обеспечения ими.
8 На основе анализа трудовых ресурсов на основе разделения труда и норм управляемости определяем требуемые подразделения.
…
…
-, Возможность и пути автоматизации учета и управления.
…
Дальше писать лениво. И так если слегка расписать получается статейка. :))bipiem Автор
27.12.2017 12:41Перенес в начало.
habrahabr.ru/post/345424/?reply_to=10588288#comment_10588536
ggo
25.12.2017 11:20Есть предположение, что например архитектуры городов существуют, а архитектуры предприятий не очень, из-за того, что разнообразие городов не очень разнообразное. Вот тут жители живут, вот здесь отдыхают, вот здесь работают, вот здесь дороги, вот здесь трубы, провода, и т.д. А предприятия существенно разнообразнее. Коммерческие, некоммерческие, государственные, производственные, научные, и т.д.
И предприятия меняются быстрее, чем города. Помогла бы Kodak, Nokia или Sun его архитектура предприятия? Была бы эта архитектура актуальной?bipiem Автор
25.12.2017 11:36«архитектуры городов» — подразумевает разночтение: архитектура города с позиции зодчества и архитектура города с позиции экономического субъекта.
Также можно сравнивать города по другим также архитектурным особенностям, например, сравните город миллионник с закрытым городом, типа «Саров» (другой менталитет жителей и соответствующий «отпечаток» на его архитектуру, ЕА города).
На мой взгляд, архитектура предприятия — также очень консервативна. Скорее меняются не архитектурные особенности, а только «бантики» (чаще — только лозунги): наращивается (или деградирует) мускульная часть, а скелет (эталонная модель, сам фреймворк) остается прежним.
Да и сама ИТ-архитектура предприятия — меняется редко, — уж слишком это дорого и рискованно. Большинство upgrade не меняют ИТ-архитектуру.ggo
26.12.2017 09:50Ну мы же под архитектурой предприятия подразумеваем все, что важно для предприятия, а не только ИТ. Так и с архитектурой города, подразумеваем все, что важно для города, а не отдельно зодчество, отдельно экономика.
То что города разные, и их архитектура отличается — очевидно. Вопрос не в этом.
Вопрос, почему хоть какие-то архитектуры городов существуют. И не в единичных случаях. А вот с архитектурами предприятий не задалось.
Имхо, все-таки в среднем не стагнирующее предприятие (что коммерческое, что некоммерческое) меняется существенно быстрее не стагнирующих городов, опять же в среднем. Примеры с Нокией и т.д. приводил из посыла, что внешняя среда изменилась, предприятие измениться не успело. И все, нет больше предприятия.
Возникла мысль, почему города меняеются медленнее. Город — финансовая группа. Городу не нужно меняться быстро, т.к. его риски размазаны среди кучи участников (предприятий). У предприятия риски остаются, ему нужно быстро меняться, чтобы выжить.bipiem Автор
26.12.2017 14:04приводил из посыла, что внешняя среда изменилась, предприятие измениться не успело. И все, нет больше предприятия.
Пока ЕА руками не поменять, она не изменится. Многое, что и «рукотворное» не меняет ЕА, например, управление тарифами не меняет ЕА, хотя может резко отразиться на «самочувствии предприятия».
У предприятия риски остаются, ему нужно быстро меняться, чтобы выжить.
Это, мне кажется, тоже классической уловкой консалтеров. Они постоянно утверждают о том, что возникли «новые условия», «нужно все менять» и что-то покупать (у них или их компаньонов), «уходить в цифру» (цифровизация \ диджитализация) и прочее.
Понятно, что бизнес по ремонту ручных швейных машинок уже видимо погиб и нужно было заранее с него «соскакивать». Но уверен, что много примеров, когда было так: «как хорошо, что я не послушал этих крутых консалтеров с их Ура-стратегией, а то бы уже лишился бизнеса».
А что Вы все про архитектуру города и ЕА? Более простые примеры есть? Домохозяйство — чем хуже? Или архитектурное описание булочной по ЕА фреймворку?ggo
27.12.2017 11:09Тут были попытки определиться с целью архитектуры. Мое глубокое имхо, главная цель архитектуры, чтобы было проще (дешевле, быстрее, прочие эпитеты по вкусу) изменять/изменяться. Еще вариант, чтобы было проще управлять. Но тут надо определиться, а что такое управлять. Опять же, по моему мнение, лучшее определение управления — это контролируемый переход их одного состояние в другое. Т.е. опять же про изменения.
Если это верно, тогда архитектура предприятия — чтобы проще изменять предприятие.
Архитектура города — чтобы проще изменять город.
Архитектура булочной — чтобы проще изменять булочную.
Но есть и другие аспекты. Количество артефактов и скорость изменений.
У булочной артефактов не так много, скорее всего легко поместятся в голову администратора булочной. Он же наверно и единственный ответственный за изменения в булочной.
Насущная необходимость архитектуры булочной в формализованном виде отсутствует как-бы.
Город и предприятие — артефактов существенно больше, в одной голове уже не помещаются. Вроде бы формальное описание архитектуры должны быть полезно. Но, имхо, начинает играть роль скорость изменений. Если изменения по наитию выполняются в два (и больше) раза быстрее, чем изменения с помощью формальной модели, при этом риск ошибок в обоих случаях отличается на проценты, то управление с помощью формальной модели начинает проигрывать. Если объем изменений, и их скорость снижаются, то управление с помощью формальной модели начинает выигрывать.
Это все измышления в попытке объяснить, почему формальные модели (архитектура) для городов, зданий существуют. А архитектуры предприятий, как байки, вроде где-то кто-то видел/слышал.
off
Когда-то в молодости проникся идеями большой четверки, касательно UML.
Обсудил в коллегами, как же теорию перенести на практику. Решили, а давайте начнем с простого, и потом перейдем в описанию более сложных. Вроде бы все логично. Через пару дней делюсь своими моделями с коллегами. В ответ, вместо восторженных рукоплесканий, слышу: ну это же итак очевидно. Зачем нужна модель в разных срезах, тратить время на ее создание, если итак все просто и очевидно.
И хотя за эти два дня созданные модели мне стали близки, пришлось признать, пользы от них было мало. Пришлось с ними расстаться и забыть про них.
Когда польза UML проявилась в полный рост? Через несколько лет, тогда когда сложность проектов серьезно выросла, и стала такой, что в голове уже не помещались все важные артефакты и их связи. И вот здесь ни у кого из сопричастных не возникало вопроса, а зачем UML и зачем нужна актуализация.
Наверно с архитектурой предприятия аналогично.
lair
27.12.2017 11:42Архитектура города — чтобы проще изменять город.
Архнадзор смотрит на вас с непониманием.
bipiem Автор
27.12.2017 22:09Не знаю как смотрит Архнадзор, но подход ggo — в русле гоголевской архитектурики (Николай Васильевичу бы понравилось):
«Но обратимся к архитектуре городов. Город нужно строить таким образом, чтобы каждая часть, каждая отдельно взятая масса домов представляла живой пейзаж. Нужно толпе домов придать игру, чтобы она, если можно так выразиться, заиграла резкостями, чтобы она вдруг врезалась в память и преследовала бы воображение…
Масса города имеет уже тем выгоду, что ее вдруг можно изменить, исправить по своему произволу.»
«Об архитектуре нынешнего времени»lair
28.12.2017 11:26Я не знаю, что такое архитектурика, но я что-то не слышал, чтобы Гоголь был хорошим архитектором. И это не говоря о том, что мне кажется, что он имеет в виду совсем не то же самое, что и вы.
ggo
28.12.2017 09:59С непониманием, в том смысле, что архнадзор — субъект, препятствующий изменениям?
Как бы там ни было, но города меняются. Потому что люди и окружающие условия меняются. Переселяются, меняются приоритеты и вкусы. Сколько сейчас авто? Сколько их было 20 лет назад? Сколько потребляет энергии домохозяйство? Сколько потребляло 20 лет назад? Сколько отходов генерирует домохозяйство? Сколько 20 лет назад? И т.д.
Что должен делать тот, кто управляет городом? Изменять его под новые условия.
Некоторое время назад должность Главного архитектора города предполагала не только ответственность за зодчество, но и прочие аспекты (togaf view) деятельности города. Что делал архитектор города — выявление перекосов между потребностями и возможностями города, текущими и будущими, и контроль планирования и реализации мероприятий (transformation).
Вот и еще одна параллель между городом и предприятием, архитектор предприятия делает на предприятии то же, что архитектор города в городе.lair
28.12.2017 11:28С непониманием, в том смысле, что архнадзор — субъект, препятствующий изменениям?
Неуместным изменениям.
Что должен делать тот, кто управляет городом? Изменять его под новые условия.
Если изменение необходимо. Так же и архитектура — она не для того, чтобы было легко изменять, она для того, чтобы решать задачи. Если решение задач требует изменения — тогда будет изменение.
bipiem Автор
28.12.2017 12:55выявление перекосов между потребностями и возможностями
Ключевое выражение «выявление потребностей и их удовлетворение» — это базовая формула для любых фреймворков ЕА: государства, города, предприятия, малого предприятия, домохозяйства, человека.
bipiem Автор
27.12.2017 13:26Если это верно, тогда архитектура предприятия — чтобы проще изменять предприятие.
Видимо, прежде чем что-то изменять, вначале нужно что-то построить.
Почему Вы не рассматриваете архитектурный подход именно под «разработку предприятия». Его же проще строить под уже апробированную архитектуру, взять за основу проверенную «эталонную модель» и т.п.
Насущная необходимость архитектуры булочной в формализованном виде отсутствует как-бы.
Для тех, кто знает наизусть таблицу умножения, " Насущная необходимость" наличия таблицы умножения на обложке каждой тетрадки — видимо тоже отсутствует.
Тем не менее, эту табличку постоянно печатают и печатают. Некоторые ее десятилетиями помнили, а сейчас уже и не всю.
Это все измышления в попытке объяснить, почему формальные модели (архитектура) для городов, зданий существуют. А архитектуры предприятий, как байки, вроде где-то кто-то видел/слышал.
С этим — согласен.
Одним из важных отличий архитектурного подхода в ЕА\ НА от объектов зодчества и процессоров действительно заключается в статичности (во всяком случае, консерватизме).
Изделие «процессор» (как конкретный экземпляр объекта типа «процессор») фактически не претерпевает изменений своей архитектуры на протяжении всего ЖЦ.
Изделие зодчества (строение) от изначально заложенной архитектуры (при строительстве) может через реконструкцию изменить (частично) архитектуру: спустя время половину здания перестроили под другой архитектурный стиль.
Это исключение, но потенциальная возможность.
Архитектура предприятия и НА может быть также подвижной, хотя они все равно консервативны. Обычно для изменения архитектуры домохозяйства нужны веские причины (потрясения), переосмысление принципов ведения домохозяйства, прежних домоустоев.
Архитектура НА часто меняется при событиях: «дети выросли», «прежние домочадцы съехали» (другие изменения состава семьи — орг-штата НА), «хозяева НА изменили статус» (вышли на пенсию), изменение бизнес-модели НА: потеря прежних доходов или наоборот «попали в русло и деньги стали сыпаться фактически с неба».
Есть и другие отличия мета архитектур. Например, видимость архитектур т.е. одни видны невооруженным глазом — зодчество, другие — только с применением специальных устройств \ методов (архитектура процессоров).
когда сложность проектов серьезно выросла, и стала такой, что в голове уже не помещались все важные артефакты и их связи.
Да, верно именно об этом ЕА и НА. Только нужен математический аппарат для построения таких моделей, а собственно базовые (типовые) варианты и будут архитектурами — архитектурными стилями предприятий и домохозяйств (ЕА и НА).
Поэтому я также призываю: а давайте начнем с простого, и потом перейдем в описанию более сложных.
Только в открытом доступе нет ни «простого», ни " более сложных". Это и есть одно из подтверждений алхимии в ЕА.ggo
28.12.2017 10:35Где-то, наверно, повторюсь. Имхо, если не ссылаться на академические источники, архитектура предприятия — это модель, описывающая разные срезы (реальные или воображаемые) предприятия. И это модель служит ровно для одного — помогать тому, кто управляет предприятием, изменять его (тут немного тавтология, т.к. чуть ранее выяснили понятийную близость управления и изменения).
Соответственно архитектура предприятия сама по себе не может быть статичной или подвижной. Архитектура изменяется с той скоростью, с какой меняется само предприятие.
На этапе строительства предприятия с нуля — возможность переиспользования архитектурных шаблонов — жирный плюс. Да и «строить» с нуля, вообще жирный плюс, любой ИТ-ник подтвердит. Но сколько предприятий «в масле» в год появляется? И сколько продолжает свою деятельность с прошлого года? Что делают вторые? Наверно у них тоже происходят изменения.
В целом потребность в наглядных примерах EA подтверждаю. Слишком много побочной информации. Условно UML for dummies есть, а Archimate for dummies нет, только стандарт.
Но уверенности, что простые объекты подойдут в качестве кандидатов для препарирования под лупой EA, нет.
lotse8
25.12.2017 19:39Про цели никто не упоминает. Все же нужно «плясать от печки», т.е. от целей. Архитектура тюрьмы и архитектура дома отдыха будут отличаться, я так думаю. Аналогично и архитектура домохозяйства будет отличаться в зависимости от целей.
Все лучшее детям — одна архитектура. Бери от жизни все — другая архитектура.
После целей идет главная полезная функция предприятия: родить и воспитать детей — или кайф по полной. И уже под это строится все остальное — сущности и процессы.
Может быть автор цели подразумевал, но не осветил в своей статье?
«И таки да» (с), архитектуры предприятий с аналогичными целями теоретически должны быть идентичными, но еще есть такая поправка как местные условия.bipiem Автор
25.12.2017 19:49Все же нужно «плясать от печки», т.е. от целей.
Архитектура тюрьмы и архитектура дома отдыха будут отличаться, я так думаю.
Интересно – это как же? Если в монастыре стиля такого-то разместить тюрьму, то что: арки выпрямятся, а колонны изогнутся?
Например, Данилов монастырь – как тюрьма для малолеток в 1930 – м изменила его архитектуру (зодчество)?
Так же и для предприятий: предприятия с разными целями могут иметь идентичную архитектуру. Почему нет?lotse8
25.12.2017 21:57С данным примером Вы правы, возразить нечего. Одно и то же изделие можно использовать под разные цели. В микроскоп можно смотреть, а можно им и гвозди забивать.
Тогда можно сделать вывод, что понятие «архитектура» в смысле зодчества для предприятий вообще не прменимо. Предприятие — это система, созданная для определенных целей, с соответствующими целям сущностями и процессами.
И всех, кто заводит разговоры об «архитектуре предприятия» сразу приземлять на уровень системы и вести предметный разговор в терминологии систем (сложных и не очень). Тогда всем будет ясно и понятно, о чем речь.
О системах писано немало, и примерам построения систем тоже нет числа.
Термин «архитектура предприятия» заклеймим как шулерство маркетологов.
Что скажете?lair
25.12.2017 22:19Тогда можно сделать вывод, что понятие «архитектура» в смысле зодчества для предприятий вообще не прменимо.
Удивительно, что к этому выводу все еще надо приходить, хотя это из определения очевидно.
Это, правда, совершенно не значит, что термин "архитектура предприятия" некорректен. Есть много разных "архитектур", которые давно не зодчество.
Тогда всем будет ясно и понятно, о чем речь.
Не думаю. Терминология систем — тоже штука не идеально понятная.
bipiem Автор
25.12.2017 22:59Одно и то же изделие можно использовать под разные цели. В микроскоп можно смотреть, а можно им и гвозди забивать.
Еще пример, есть четыре завода (автопром). Совершенно одинаковых, вплоть до того, что в них совершенно идентичные сервера, сети, и даже совпадают все IP-адреса во внутренней сети.
Орг-штатная сетка тоже одинаковая, численность тоже, т.е. – в вообще ничего отличительного нет (кроме географических координат). Даже маршруты документооборота (здесь бумажку взял, там положил) – все в точности совпадают.
В целом, получается, что все эти предприятия имеют идентичную архитектуру. Но цели у каждого могут быть разные:
Акционеры первого – ставят цели: нарубить как можно больше бабла прямо сейчас (и свалить за бугор, т.к. скоро перевыборы и «крыша может съехать»);
Акционеры второго — ставят цели: нарубить как можно больше бабла в перспективе 3 лет и как-то соблюдать закон, чтобы делать вид «законопослушного» (помним про 300 процентов по Марксу);
Акционеры третьего – работать три года ниже себестоимости, чтобы задушить конкурентов и только после этого «отыграть» все «причитающееся» и «упущенное».
Акционер четвертого – решил: хрен с ней – с прибылью – это вторично, сделаю-ка я отечественный ё-мобиль, так сказать подниму престиж отечественного автопрома, дам соотечественникам веру в свои силы и т.п.
Предприятия же не всегда создают «чтобы делать бабки и как можно больше».
Можно привести другие разные целеполагания, под идентичную архитектуру предприятия.
Если опуститься на уровень процессов, то один и тот же бизнес-процесс может использоваться для разных целей (даже для противоположных).
Термин «архитектура предприятия» заклеймим как шулерство маркетологов.
Сам термин «ЕА» — ни в чем не виноват. Просто ему нужно дать правильную (отвечающую применяемым в нем терминам) трактовку, показать обманчивость его текущей трактовки алхимиками. Правильную трактовку подтвердить опубликованными примерами, тем самым показать разные архитектуры и саму сущность архитектурного подхода при моделировании объектов типа «предприятие» (домохозяйство).lair
26.12.2017 11:51В целом, получается, что все эти предприятия имеют идентичную архитектуру.
И снова зависит от определения архитектуры.
lotse8
26.12.2017 20:02Вы валите все в одну кучу — цели предприятия и цели владельцев, а это не одно и то же. Цель автозавода — автомобили выпускать, поэтому и архитектура автозаводов может быть похожа.
Цели владельцев другие — поэтому архитектура финансовых потоков у них вероятно разная.
Терминология четко не определена, поэтому нет однозначного понимания, отсюда и проблемы.
Для начала определиться бы с формой и содержанием. В одну и ту же форму можно впихнуть разное содержание, и результат будет не один и тот же. Если Вы под архитектурой хотите понимать только форму, то архитектура вообще тогда не имеет никакого значения. Кофе, воду или водку можно пить из вазы, из бокала, из чашки, из пластикового стаканчика и т.д. Это для содержания не имеет никакого значения, дело вкуса.
Форма в некоторых случаях тоже имеет значение, если рассматривать примеры ближе к предприятию, то не всякое оборудование может работать при любой температуре, поэтому помещение должно соответствовать. Но в случае предприятия форма зависит от содержания.
Лучше не мучайте себя архитектурой, а рассматривайте предприятие как систему. Вопросов однозначно меньше будет.
Архитекторы будут продавать свои архитектуры пока на них будет спрос. И если кто-то хочет избавить себя от лишних денег, то не нужно ему в этом мешать.bipiem Автор
26.12.2017 23:54Цель автозавода — автомобили выпускать
Выдвину предположение, что у автозавода не может быть цели. Цель может быть у роли или у процесса.
Терминология четко не определена, поэтому нет однозначного понимания, отсюда и проблемы.
И я ровно о том же. Не показывают алхимики примеров ЕА. Все (включая, терминологию) стараются запутать.
Для начала определиться бы с формой и содержанием.
В качестве «формы» можно взять форматку Захмана и наполнить ее содержанием. Кто-нибудь пробовал? Лучше отталкиваться от каких-то базовых подходов: List of things \ List of processes …
Это ни чем не хуже, чем через упомянутые Вами: форма и содержание.
Лучше не мучайте себя архитектурой, а рассматривайте предприятие как систему.
А это как? Парой предложений это вряд ли пояснить.
И если кто-то хочет избавить себя от лишних денег, то не нужно ему в этом мешать.
В большинстве случаев, нас – налогоплательщиков «избавляют от лишних» денег. Причем без нашего согласия.
lair
25.12.2017 22:17Если в монастыре стиля такого-то разместить тюрьму, то что: арки выпрямятся, а колонны изогнутся?
А это зависит от определения архитектуры. Архитектурный стиль — не изменится (хотя тоже, конечно, зависит от степени вмешательства в постройку, советую на севильский собор посмотреть).
bipiem Автор
25.12.2017 23:18Lair – мое почтение.
Севильский кафедральный собор = готическая архитектура. Разве нет?
Мы же говорили, что архитектура (что храма, что процессора, что предприятия) обычно не зависит от масштаба и материалов и т.п. На то она и «архитектура».
Я в статье показывал, что «архитектура» в смысле зодчества и для процессоров и для предприятий, других систем (архитектура системы — как концепция) – имеют одинаковый смыл. В чем противоречие?
Желательно на примерах.
Да, и расскажите, как можно говорить о «текущем» понятии ЕА, если так и нет ни одного примера этой самой загадочной архитектуры (ЕА)?
Например, архитектуру зодчества – пожалуйста – примеров масса, архитектур процессоров – также навалом.
Может нужно начать с рассмотрения конкретных архитектур предприятия и только потом в этих примерах нащупать «архитектурность» и скорректировать общее представление о термине «архитектура» применительно к предприятиям?
Разве это не само собой напрашивающийся путь? Или лучше прятать примеры ЕА и рассуждать об «архитектуре предприятия» с позиции алхимии?ggo
26.12.2017 09:54Имхо, тут начали скатываться с частностям. Архитектура зодчества — лишь один из срезов общей архитектуры (пусть будет города, или района). Примерно как ИТ-архитектура для предприятия. Но нам же интересен не один срез, и их некоторое количество?
bipiem Автор
27.12.2017 13:41Но нам же интересен не один срез, и их некоторое количество?
Не понял мысли.
Нам интересны сами архитектуры («сами по себе»). Они образуют конечное и небольшое множество. Огромное множество сооружений, процессоров и предприятий содержат конкретную архитектуру из небольшого множества (архитектурного множества, набора архитектур).ggo
28.12.2017 09:36Архитектура зодчества, если я ее правильно понял, применительно к архитектуре здания или города, является лишь одним из срезов (view из приснопамятного togaf'а) общей архитектура здания/города. В общем случае, управляющему/владельцу здания/города интересны не только внешний облик и строительные особенности, но и другие срезы, коммерция, культура, экология, энергия, транспорт и т.д.
Т.е. архитектура зодчества хоть и наглядный пример, но имхо однобокий.
Условно, управляющему/владельцу здания недостаточно иметь только строительные чертежи и арх.эскизы для того же арх.надзора.lair
28.12.2017 11:29Архитектура зодчества, если я ее правильно понял, применительно к архитектуре здания или города, является лишь одним из срезов (view из приснопамятного togaf'а) общей архитектура здания/города
Нет такой вещи как "общая архитектура здания, отличная от архитектуры в смысле зодчества". То, что вы описываете дальше, архитектурой здания никто никогда не называет.
bipiem Автор
28.12.2017 12:42В статье про это есть ссылка:
Мне близок взгляд на архитектуру, показанный в dragon1
www.dragon1.com/resources/dragon1/architecture
«Архитектурный подход» (архитектурика, формализация мета архитектур) к описанию предприятия мы сравниваем с аналогичными подходами в зодчестве и электронике (процессоры).
Применительно к архитектуре здания (архитектурный фреймворк зодчества): посмотрев «невооруженным взглядом» на здание типа «храм» и открыв каталог архитектур зодчества, можно соотнести архитектуру конкретного храма с типовой (эталонной).
Наберите в wiki любой собор — и там (в кратком паспорте сооружения, см. справа) будет «готика» (готические соборы) или что-то другое (но конкретное).
Отечественные процессоры с архитектурой х86 были поострены путем послойного копирования топологии американских микросхем. Кстати, подобное для современных процессоров современной капиталистической России давно «не по зубам» ни комерсам, ни ВПК.
Идентифицировать архитектуру х86 можно и программным путем (анализ системы команд, разрядности и т.п.).
Вот с архитектурой предприятия — подобное невозможно.
Пока для формализации и идентификации ЕА нет инструментария, а только субъективный подход и алхимия. Когда-нибудь изобретут метод «объективного контроля» и формализации, научатся «фотографировать» процессы, логические объекты и отношения, далее перейдут к цифровому распознаванию бизнес-процессов и архитектуры предприятия.
Эти технологии будут подобны дистанционному зондированию Земли или раскрытию сети (HP NMM и прочее).
Вот «архитектура города» — действительно дает разночтение. Какой объект рассматривается?
Если объект «градостроительство», то да, родственное «архитектура зодчества». Пример из гоголевской архитектурике привел ранее: habrahabr.ru/post/345424/?reply_to=10590392#comment_10589776
Если рассматривается «город», как объект класса «предприятие», т.е. экономическая сущность (не ИТ-сущность, ведь верно?), то говорить об «архитектуре зодчества» уже нет смысла — это другой объект анализа и городская планировка \ застройка если и будет отражена в описании «Архитектура предприятия», то лишь штрихом, т.к. не является ключевым объектом архитектурного описания (по ЕА-фреймворку).
Вы все про архитектуру городов — про сложные объекты, почему вначале не рассмотреть простые, например, НА? А потом только вернуться к сложным?lair
28.12.2017 13:09посмотрев «невооруженным взглядом» на здание типа «храм» и открыв каталог архитектур зодчества, можно соотнести архитектуру конкретного храма с типовой (эталонной).
… и что такое "эталонная архитектура храма"? Вот конкретно, списком.
Наберите в wiki любой собор — и там (в кратком паспорте сооружения, см. справа) будет «готика» (готические соборы) или что-то другое (но конкретное).
Это, как уже говорилось ранее, архитектурный стиль. Вы можете взять три собора, из которых два — готические, а один — романский, и внезапно выяснить, что с точки зрения организации пространства (функциональная архитектура) один из готических ближе к романскому, чем к другому готическому.
bipiem Автор
28.12.2017 14:36как уже говорилось ранее, архитектурный стиль. Вы можете взять три собора, …
как уже говорилось ранее (в статье), архитектурный стиль (в зодчестве) = архитектура. И была ссылка, подтверждающая это (на Вику).
Точно также, как «архитектура предприятия» = «архитектурный стиль предприятия».
Повторюсь, что спорить об архитектурах (стилях) «зодчества» и «процессоров» — это нормально, они объективно подтверждены. Чтобы объективно подтвердить наличие архитектуры у предприятия — для этого нужны как минимум образцы архитектур, которые алхимики не показывают.
Может вообще, нет никаких архитектур у предприятий?
Поэтому, я и призываю, собрать некоторое количество архитектур домохозяйств (домашних хозяйств, как домашних организаций), чтобы хотя бы на них посмотреть, что же такое «архитектура предприятия».
Может быть, сосредоточить усилия на этом? Не передумали? Участвуете (раздел №3 статьи)?
Что касается наличия разных архитектурных особенностей в одном строении (соборе), то также я показывал, что если изначально у готического собора половину разрушить и пристроить «хайтек», то получится комбинация архитектур. Но это скорее исключение, чем правило.
Конкретное предприятие также может сочетать несколько архитектур (архитектурных решений, стилей), но можно выявить превалирующую, и точно указать, где какая. Не вижу противоречий.lair
28.12.2017 14:43как уже говорилось ранее (в статье), архитектурный стиль (в зодчестве) = архитектура. И были ссылки подтверждающие это (на Вику).
… опровергающий комментарий вы проигнорировали, я заметил.
Точно также, как «архитектура предприятия» = «архитектурный стиль предприятия».
Нет никакого "точно так же". Нет переноса терминов между архитектурой зданий и архитектурой предприятий.
Может вообще, нет никаких архитектур у предприятий?
Есть. Потому что есть дисциплина, которая так называется. Вам может не нравиться, что она так называется, и вы имеете право этой дисциплиной не пользоваться. Вы можете считать, что эта дисциплина не приносит вам пользы, и опять-таки ей не пользоваться. Но она есть.
Что касается наличия разных архитектурных особенностей в одном строении (соборе), то также я показывал, что если изначально у готического собора половину разрушить и пристроить «хайтек», то получится комбинация архитектур.
И снова нет. У этого собора будет одна архитектура (в несловарном значении "совокупность принятых конструкторских решений"), но несколько архитектурных стилей.
И эта проблема опять возникает из того, что вы, на самом деле, не используете никакое формальное определение понятия "архитектура" применительно к постройкам, вы опираетесь на свое обывательско-интуитивное понимание.
Но это скорее исключение, чем правило.
Вы, видимо, видели мало европейских соборов. Пока что практически каждый, в котором я был, захватывает больше одного архитектурного (или декоративного) стиля, просто потому, что здания не так долговечны, как нам хотелось бы.
bipiem Автор
28.12.2017 15:04что такое «эталонная архитектура храма»?
Храмовая архитектура
Там есть список (см. содержание), но он далеко не полный.
И снова нет. У этого собора будет одна архитектура (в несловарном значении «совокупность принятых конструкторских решений»), но несколько архитектурных стилей.
Смотрите Вику: там ОДНА строка: «архитектурный стиль» с ОДНИМ значением, например, «готическая архитектура».
Например, по Вашему же Севильскому
По-Вашему: составители Вики, все как один «опираются на свое обывательско-интуитивное понимание»? Тогда оно, видимо, и есть объективное.
Про архитектуру непосредственно домохозяйства что скажите?
Архитектурные стили и подходы к архитектурам зодчества обсудили предостаточно, нам бы так детально подходы к архитектурам предприятий и домохозяйств обсудить бы (цель статьи).lair
28.12.2017 15:13Храмовая архитектура
Там есть список (см. содержание), но он далеко не полный.Это список архитектурных стилей, в которых строятся храмы. Нет.
Я повторяю свой вопрос: что такое, конкретно, "эталонная архитектура храма". Приведите пример.
Смотрите Вику: там ОДНА строка: «архитектурный стиль» с ОДНИМ значением, например, «готическая архитектура».
… и что? Вы хотите, чтобы в статье в страницу размером были описаны все нюансы? Неизбежно будут упрощения. Если бы была необходимость в точном определении, сказали бы "доминирующая архитектура".
Про архитектуру непосредственно домохозяйства что скажите?
Скажу, что нет определения, что это такое, и мне это не интересно.
bipiem Автор
28.12.2017 15:41-1Скажу, что нет определения, что это такое, и мне это не интересно.
Ну, наконец-то, теперь мне понятно: Вас не интересуют ЕА \ НА (архитектуры, архитектурные стили, фреймворки, предприятия), а только интересуют архитектуры и \ или архитектурные стили зодчества. К сожалению, эта статья не про зодчество и архитектуру ее объектов. Извините.lair
28.12.2017 15:49Ну, наконец-то, теперь мне понятно: Вас не интересуют ЕА \ НА (архитектуры, архитектурные стили, фреймворки, предприятия), а только интересуют архитектуры и \ или архитектурные стили зодчества.
Если бы не слово "только", я бы даже с вами согласился.
К сожалению, эта статья не про зодчество и архитектуру ее объектов.
Это не оправдывает некорректное использование терминов.
lair
26.12.2017 12:02Севильский кафедральный собор = готическая архитектура. Разве нет?
Если вас не смущает, что Patio de los Naranjos — это двор мечети, а Giralda — ее минарет (и, если верить вашему примеру с монастырем, архитектура не должна была измениться). И если закрыть глаза на ренессансные и барочные участки, которых там много.
Мы же говорили, что архитектура (что храма, что процессора, что предприятия) обычно не зависит от масштаба и материалов и т.п. На то она и «архитектура».
Вы говорили. Но вы это не доказали. И если вы попробуете рассказать архитектору зданий, что архитектура здания не зависит от материала, а архитектору программной системы, что архитектура ПО не зависит от масштаба, то они оба посмотрят на вас удивленно.
Я в статье показывал, что «архитектура» в смысле зодчества и для процессоров и для предприятий, других систем (архитектура системы — как концепция) – имеют одинаковый смыл. В чем противоречие?
Очень просто. Архитектура в смысле зодчества — это "искусство и наука строить, проектировать здания и сооружения". Деятельность. Архитектура набора команд (то, что иногда называют архитектурой компьютера) — это абстрактная модель компьютера (типы данных, модель IO, состояние, набор команд). Абстракция. Сравнивать одно с другим — это сравнивать дельфинов с апельсинами. Нет, у них не одинаковый смысл.
И да, на всякий случай. Когда говорят "архитектура Древнего Египта", имеют в виду приблизительно то же самое, что и "музыка Древнего Египта", а именно — обобщенное описание всех произведений данного вида деятельности там и тогда; то, какое развитие получила эта деятельность и какие формы она принимала.
Может нужно начать с рассмотрения конкретных архитектур предприятия и только потом в этих примерах нащупать «архитектурность» и скорректировать общее представление о термине «архитектура» применительно к предприятиям?
Вы не можете так сделать, не определив понятие "архитектура предприятия", потому что вы не знаете, что именно в предприятии рассматривать.
bipiem Автор
26.12.2017 13:02Вы не можете так сделать, не определив понятие «архитектура предприятия», потому что вы не знаете, что именно в предприятии рассматривать.
«нужно начать с рассмотрения конкретных архитектур предприятия» хотя бы тех «архитектур», которые существуют в понимании консалтеров (архитекторов).
Проектов по ЕА много. Даже если там и описание не ЕА (но выдается за ЕА, т.е. как с надписью на сарае, где дрова лежат), то хотя бы будет «хоть что-то, что можно сравнивать хоть с чем-то».
Зачем спорить о том, какого цвета что-то, что мы не видели? Лучше посмотреть на томик проекта с заглавием ЕА и сказать какого оно «цвета», т.е. о какой архитектуре вообще речь.
Пока алхимики лишь говорят, что они всё видели и знают толк в «настоящей архитектуре».
Только такой ответ меня не устраивает.
вы не знаете, что именно в предприятии рассматривать.
Поэтому я и предлагаю не начинать со сложных вещей, а попробовать разобраться на простых примерах, например, НА.
Однако с простыми примерами некоторым боязно иметь дело, т.к. алхимия может быть легко раскрыта.
Вот алхимикам и приходиться хитрить: «мы работаем только со сложными системами — Масштаба предприятия и только по NDA, а простые примеры ЕА рассматривать не желаем, т.к. это „не наш уровень“.lair
26.12.2017 13:06«нужно начать с рассмотрения конкретных архитектур предприятия» хотя бы тех «архитектур», которые существуют в понимании консалтеров (архитекторов)
А, благое начинание. Удачи.
bipiem Автор
26.12.2017 16:24Спасибо.
Помощников и сподвижников бы. В одиночку армию алхимиков не одолеть.lair
26.12.2017 16:34… и вы удивляетесь, почему никто из занимающихся EA не хочет с вами сотрудничать?
bipiem Автор
26.12.2017 17:18… и вы удивляетесь, почему никто из занимающихся EA не хочет с вами сотрудничать?
То, что «профессионалы» (помните хоккейного комментатора: «канадские профессионалы» и «советские любители») не будут сотрудничать — в этом сомнений давно нет. Это обсуждали:
Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»
habrahabr.ru/post/300986/#comment_9637178
< … на мой взгляд, часть алхимиков осознаёт, что они выглядят алхимиками — тот же …
<< Они почти все это понимают. Только, к сожалению, они нам не помогут.
…
Мой расчет на «любителей».lair
26.12.2017 17:21А тогда не видать вам, собственно, "конкретных архитектур в понимании консалтеров".
System12
26.12.2017 22:02Вопрос об отличиях архитектуры тюрьмы и дома отдыха довольно спорен. Например тюрьмы www.infoniac.ru/news/Samye-shikarnye-tyur-my-mira.html получше многих домов отдыха. Я уже не говорю про то, что люди уже давно знали что «золотая клетка» по своей сути тоже тюрьма.
lotse8
26.12.2017 22:48Вопрос об архитектуре спорен. Нужно разобраться для начала с формой и содержанием, см. ответ выше habrahabr.ru/post/345424/?reply_to=10587454#comment_10587222
bipiem Автор
27.12.2017 00:00И как разобраться? Может быть на основе какого-нибудь существующего «знатного фреймворка»? Или Вы свой предложите?
bipiem Автор
26.12.2017 23:28Согласен.
С трудом верится в такие тюрьмы. Туда видимо очередь на несколько лет вперед, а тех кто сбежал – сразу в психушку: как можно cбежать от такой райской жизни будучи в здравом уме? Может это просто «буржуазная пропаганда»? Хотя есть и другие объяснения.
Идентичность ЕА обоих предприятий (тюрьма и пансионат) определяется во многом идентичностью их бизнес-процессов и продуктовой линейкой. Неужели они одинаковы? Скорее всего, «да». ЕА обоих указанных предприятий – могут быть действительно идентичны.
Например, за пребывание, как в пансионате, так и в такой странной «тюрьме» идет посуточная оплата «постояльца» или «арестанта».
Речь о коммерческих тюрьмах? За пребывание в таком «доме отдыха за колючей проволокой» он платит (а ценник не менее, чем за пребывание в отеле), а как только деньги закончились — его сразу в «настоящую тюрьму»?!
Тюремщики выполняют роль «следящей сиделки», о перевоспитании, скорее всего, речи нет. Т.е. основная цель тюрьмы – в этом случае исключена, т.к. арестант находится «на отдыхе» в «закрытом пансионате» купив «освобождение от классического наказания».
Думаю, при детальном рассмотрении ЕА обоих предприятий, действительно выяснится их единое «архитектурное начало».
На этом примере отчетливо видна суть «буржуазной системы» (или даже – «буржуазной архитектуры»): деньги решают все!
В советской (справедливой) архитектуре, у арестанта вначале бы конфисковали все активы, поэтому ему нечем было бы платить за подобную «индульгенцию».
dargo
27.12.2017 12:23Я рассматриваю Togaf как рекомендации для того чтобы:
— последовательно, пройдя все необходимые этапы (requirements, uses cases, point of views, application, data, technology architecture и тд) реализовать какую-то цель/стратегию/задачу бизнеса посредством ИТ
— упорядочить и поддерживать ИТ документацию предприятия состоящую из таких документов как принятые стандарты, описание ПО используемого в организации (это могут быть различные виды описания — просто диаграмма, детальное описание компонентов на уровне данных, инфраструктуры и тд)
— управление архитектурой как на уровне организации в долгосрочной перспективе (architecture board) или на уровне определенного ПО организации
В Togaf очень много деталей, но личный выбор каждого выбрать наиболее необходимые/приемлимые моменты. Все это не есть какое-то изобретение Open group, в том или ином виде подобные вещи существуют и практикуются повсеместно. Open group объединила их в документацию и выставила в свободный доступ. Иметь или не иметь сертификат — дело сугубо личное. Обвинять Open group в жадности не вижу смысла.bipiem Автор
27.12.2017 14:08Open group объединила их в документацию и выставила в свободный доступ.
Вы — как практик ТОГАФ, ответьте, пожалуйста, на вопрос: почему, несмотря на наличие в открытом доступе «пособий по алхимии» (этого и других фреймворков), — нет примеров описания предприятий по этим пособиям?
Сделали бы (сам Open group или сертифицированные им специалисты) несколько «учебных», но полных и конкретных. В чем проблема?
Вы знаете о наличии конкретных примеров описания ЕА, доступных «простым смертным» (не алхимикам)?dargo
27.12.2017 16:09Я не опираюсь на конкретные примеры, а применяю рекомендации 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.bipiem Автор
27.12.2017 17:05Спасибо за подробный ответ.
Правильно я понял, что в Вашем понимании у предприятия, у которого нет ни одного компьютера нет и «архитектуры предприятия»?
Иначе что записывать в указанный Architecture repository?dargo
27.12.2017 17:49Togaf определяет несколько типов архитектуры (http://pubs.opengroup.org/architecture/togaf9-doc/arch/), в вашем случае будет бизнес архитектура описывающая структуру предприятия, роли, сервисы, продукты, сценарии (купил-продал) и тд.
На самом деле не стоит применять Togaf на все случаи жизни, эта методология все же специфична для ИТ.bipiem Автор
27.12.2017 18:14эта методология все же специфична для ИТ.
Какую посоветуете методологию ЕА и фреймворк, которые не «специфичны для ИТ»?
- Architecture landscape
bipiem Автор
27.12.2017 12:40Перенес в начало, т.к. слишком большое вложение получилось (проследить дерево сложно):
habrahabr.ru/post/345424/?reply_to=10588288#comment_10588288
1. Берем устав предприятия и внимательно его читаем.
2. Находим высшую цель предприятия и заменяем существительное глаголом, например «Работаем для прибыли». Это доступный нам процесс высшего уровня.
3. Находим в уставе виды разрешенной деятельности и определяем какую из многоперечисленных реально выполняем.
Аналогично заменяем существительное на глагол, полученную деятельность условно говоря получая процесс «Производство продукции». Полученную деятельность рассматриваем как один из подпроцессов второго уровня.
4. Два других подпроцесса идут автоматом: «Управление» и «Обеспечение ресурсами»
5. Процесс производства наиболее просто декомпозировать на основе применения старого сетевого графика, рассматривая стрелочки на нем как его подпроцессы.
6. Анализируем требуемые ресурсы, начиная с инфраструктуры.
7 Из анализа потребностей в ресурсах получаем требуемые процессы обеспечения ими.
8 На основе анализа трудовых ресурсов на основе разделения труда и норм управляемости определяем требуемые подразделения.
…
…
-, Возможность и пути автоматизации учета и управления.
…
Дальше писать лениво. И так если слегка расписать получается статейка. :))
Алгоритм для BPM или ЕА?
Дальше писать лениво. И так если слегка расписать получается статейка. :))
Статейки еще нет, но все равно спасибо (ждем продолжения). Только мы же не алхимики и всегда ставим ключевую фразу: где апробация, где конкретный пример?
На конкретном примере (хотя простом, например, булочной) можете показать?
Потом, мне кажется, если идти не от реальности, а от формальности (устав, лицензии и т.п.), то можно получить и архитектуру (или список процессов) де-юре, а не де-факто.
определяем какую из многоперечисленных реально выполняем.
А если там «малоперечисленные» или многие из реальных бизнес-процессов напрямую не вытекают из пункта №2?
8 На основе анализа трудовых ресурсов на основе разделения труда и норм управляемости определяем требуемые подразделения.
Что за нормы управляемости? Основы разделения?
Может быть, проще у самих подразделений спросить: в каких процессах они задействованы? Мы же делаем описание (архитектурное) «как есть».System12
27.12.2017 17:591. Алгоритм универсален и не раз проверен на практике.
2. Ответ на все Ваши вопросы (с примерами) тянет на целую книгу.
3. Посмотрите Устав любого ООО «Рога и копыта». В перечне видов деятельности чего только не пишут, вплоть до защиты государственной тайны, хотя реально — ларек с пивом.
4 Нормы управляемости известны с древних времен. Один начальник может непосредственно управлять только ограниченным количеством подчиненных (в зависимости от сложности исполняемой ими работы). Обычно около 10 человек. Даже в порядочных гаремах назначают старшую жену и главного евнуха чтобы не утонуть в разборе мелочевки.bipiem Автор
27.12.2017 18:261. Алгоритм универсален и не раз проверен на практике.
Повторный вопрос — ссылка?
2. Ответ на все Ваши вопросы (с примерами) тянет на целую книгу.
Хоть что-то бы и хоть с каким-нибудь куцым примерчиком. Ведь реально имеем «ноль».
В перечне видов деятельности чего только не пишут, вплоть до защиты государственной тайны, хотя реально — ларек с пивом.
Это не только с уставом. Со многими другими артефактами тоже, включая описание бизнес-процессов, см. заставку к
habrahabr.ru/post/305720
as really is
Однако, наверняка изобретут метод «объективного контроля» и формализации (фотографирования, цифрового распознавания бизнес-процессов и т.п.).
Жаль, но конкретными примерами Вы нас пока не порадовали (надеюсь что увидим).
Хотя посыл «что всё знаете» — донесли четко («не раз проверен на практике», «дальше писать лениво» и т.п.).System12
27.12.2017 18:59Вы когда-нибудь были на лекциях или семинарах иноземных Гуру? Мне запомнилось главное: В самом рассказе все излагается как для неграмотных дебилов, а на любой конкретный вопрос следует ответ: «Это консалтинговый вопрос. Мы на него ответим только после заключения договора на консалтинг!» :))
Здесь Вашу статью с примерами обсуждают или мою? :))
Это я к тому, повторюсь, что если мне подробно и с примерами отвечать на Ваши вопросы, то мне надо написать минимум брошюру, а то и целую книгу. Требовать такое количество материала как минимум неприлично. Не тот формат. :))bipiem Автор
27.12.2017 20:47С примером по гуру — согласен. Также говорят и алхимики ЕА, про это указал в п. 1.3.1:
Попытки «Посмотреть на конкретный пример ЕА» все как один (два): или «купи проект по ЕА» или (самый дешевый) «пройдите наш платный курс, мы вам ТАМ покажем (и то «по очень большому секрету»)».
Требовать такое количество материала как минимум неприлично. Не тот формат. :))
Нет, — так нет. Хотя не понятно почему не привести хотя бы пару малюсеньких конкретных примерчиков.
Надеюсь Вы в конкурсе на простую НА (см. п. №3) поучаствуете? Пожалуйста, очень просим.
Тем самым Вы внесете существенный (или скромный, все от Вас зависит) вклад — как в борьбу с алхимией и наукообразием в ЕА, так и в сотворении научного архитектурного подхода (архитектурика) к описанию предприятия типа «домохозяйство».
Bonart
Да уж, сколько ни читал про все эти архитектуры предприятия и бизнес-процессы — все равно содержательная часть сводилась к обычным диаграммам и блок-схемам.