Pull to refresh

Enterprise Architecture vs алхимия предприятия. Ключевые мифы

Reading time 29 min
Views 27K


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

Это справедливо и для современной дисциплины «Архитектура предприятия», нужно лишь сделать два уточнения: «алхимиками в 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 Länder, vereinigt euch!

Представьте, какая досада охватит многих алхимиков, когда:

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

Ваш, bipiem
Tags:
Hubs:
+15
Comments 87
Comments Comments 87

Articles