Enterprise Architecture vs алхимия предприятия. Ключевые мифы
Алхимиками двигало примерно то же, что и современными учёными — им хотелось понять, как устроен мир. Они изучали это как могли. Позже древние протонауки эволюционировали до современного состояния наук.
Это справедливо и для современной дисциплины «Архитектура предприятия», нужно лишь сделать два уточнения: «алхимиками в 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): www.cioindex.com/nm/articlefiles/4437-FrameworkEnterpriseArchitecture.pdf
Zachman92 (5×6): www.jfsowa.com/pubs/sowazach.pdf
Точнее использовано название 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 en.wikipedia.org/wiki/Enterprise_architecture
— Ivar Jacobson: Большинство инициатив EA не удалось. Я предполагаю, что более 90% никогда не приводили к чему-либо полезному »;
— Erasmus University Rotterdam IDS Scheer: две трети проектов ЕА не смогли улучшить «выравнивание» бизнеса и ИТ.
«Business and IT alignment» — слов-то каких напридумывали. Термин ввели, видимо, чтобы хоть как то «оправдать» внедрение дорогостоящих ИТ-систем, которые не обеспечивают адекватную (точнее хоть какую-нибудь) отдачу от инвестиций в ИТ: типа причина — в невежестве бизнеса, который сильно «отстает от передового ИТ» (т.е. очень дорогого ИТ).
Сами Автоматизаторы — «белые и пушистые», но вот «темный» бизнес не понял их «глубокого замысла», поэтому и неудачи на проектах ЕА (про неудачи также не принято рассказывать).
Иногда ЕА используется (замаскировано) — в качестве «мостика» — как желание CIO «порулить бизнесом» или хотя бы стоять на капитанском мостике на равных, а не представить ИТ — лишь как одно из обеспечивающих подразделений компании;
— Stanley B. Gaver: федеральная ЕА-программа в целом потерпела неудачу.
В пользу доводов Гавера можно сказать, что если что-то подобное (FEA \ FEAF или другие ЕА) действительно сработало бы и USA также, как и ARPANET передали бы технологию мировому сообществу, т
