Что такое корпоративный архитектор
Корпоративный архитектор
Корпоративный архитектор – это специалист по разработке структуры корпоративной системы программного обеспечения (ПО), её проектированию и контролю за ходом реализации. Он принимает решения по внутреннему устройству и внешнему интерфейсу ПО, сверяясь с требованиями проекта и существующими ресурсами. Кстати, в 2021 году центр профориентации ПрофГид разработал точный тест на профориентацию. Он сам расскажет вам, какие профессии вам подходят, даст заключение о вашем типе личности и интеллекте.
Профессия корпоративного архитектора появилась сравнительно недавно, хотя теоретическая концепция корпоративной архитектуры возникла много лет назад, когда произошёл переход к сервис-ориентированной архитектуре. Это позволило использовать IT-компоненты одновременно в нескольких приложениях. И здесь стал необходим специалист, который присматривал бы за всей компьютерной средой.
Информационные технологии прогрессируют так стремительно, что в какой-то момент развитие бизнеса начинает не соответствовать им. Для поддержания этого баланса и необходим архитектор, который является продвинутым специалистом в вопросах информационных технологий и хорошо разбирающимся в тонкостях конкретного бизнеса. Корпоративный архитектор принимает ответственные решения, связанные с информационными технологиями, учитывая их влияние на бизнес компании в целом.
Именно корпоративному архитектору принадлежит право принятия оптимального решения по разбивке системы на модули и определению способов их взаимодействия, чтобы в целом система максимально соответствовала требованиям заказчика и возможностям разработчиков.
Учитывая специальные бизнес-требования к программному продукту, архитектор создаёт техническую и функциональную спецификации системы, методы и технологии технической реализации. После этого команда программистов начинает работу над отдельными модулями.
Архитектору, кроме прочего, нужно быть дальновидным стратегом для того, чтобы созданная им система в будущем могла подвергаться корректировке, расширению, созданию новых версий.
Особенности профессии
Функциональные обязанности архитектора включают в себя:
Плюсы и минусы профессии
Плюсы
Минусы
Место работы
Крупные финансовые и брокерские компании, бизнес-корпорации, системные интеграторы, банки, инвест-банки
Ценность архитектора обратно пропорциональна количеству принимаемых им решений.
Важные качества
Обучение на Корпоративного архитектора
Курсы
Оплата труда
Зарплата корпоративного архитектора на декабрь 2021
Информации о зарплатах предоставлена порталом hh.ru.
Ступеньки карьеры и перспективы
Несмотря на наше утверждение о том, что архитектор — высшая ступень карьеры программиста, есть 2 направления, в которых архитектор может развиваться:
VP of Engineering — это технический директор.
Пример вакансии корпоративного архитектора на сайте https://hh.ru/vacancy/15865588
Обязанности:
Требования:
Кто такой системный архитектор
— Почему я здесь?
— Твоя жизнь — это сумма остатков неуравновешенного уравнения, свойственного программированию Матрицы. Ты — возможный результат аномалии, которую, несмотря на мои искренние усилия, мне не удалось устранить из того, что в противном случае было бы гармонией математической точности.
Мир развивается. Прогресс не стоит на месте. То, что когда-то казалось фантастикой, сейчас становится обыденностью. Всё стремится к технологической сингулярности, совершенству и удобству — минимум действий, максимум возможностей. Это неспроста, ведь вычислительные платформы усложняются и множатся, возникают новые инструменты для преодоления тех или иных проблем и задач. И так сложилось, что сегодня любое крупное или не очень цифровое решение является сложной структурой, которая разработана под конкретные запросы и требования заказчика. Потому, чтобы не было проблем, а проект отработан четко, нужны люди с соответствующей квалификацией. А значит, сегодня мы поговорим за профессию 21 века — системного архитектора. Работа, связанная с проектированием IT-инфраструктуры информационных систем, высоко ценится на рынке труда. Ведь условия в нашем быстро меняющемся мире таковы, что цифровые нововведения становятся все более и более распространенными, они внедряются не только на корпоративном уровне, но и банально, даже в обычном быту. Следовательно, появляется необходимость в специалистах, которые могут проанализировать все процессы использования цифровых технологий на разных уровнях и создать единую архитектуру организации.
А в чём заключается работа IT-архитектора?
Множество вещей предстоит сделать системному архитектору во время работы над проектом, но большинство из них определяются надобностью в данный момент, сложностью самого проекта и, конечно же, квалификацией самого архитектора, но даже из довольно массивного перечня задач можно выделить основные:
Олег Филимошин — архитектор Timeweb Cloud
По своей сути, выражаясь художественно, системные архитекторы — это первокрасные кардиологи-хирурги от мира IT, проводя высококлассные операции на «сердце» IT-инфраструктуры. Потому, крупный бизнес, чья инфраструктура построена на взаимодействии между технологическими элементами, не выжила бы в столь суровом мире цифровых технологий.
Какие знания будут полезны системному архитектору?
Требования к кандидатам на должность инженера проекта довольно высокие, что уже можно понять по сфере деятельности данной профессии. Есть ряд обязательных и желательных навыков, которыми должен обладать человек, претендующий на это место. Рассмотрим самые важные аспекты.
Одного знания языков программирования недостаточно, поскольку главное требование —иметь практический опыт, то есть напрямую участвовать в разработке. В вакансиях вы часто увидите такие требования:
К часто требуемым навыкам еще можно отнести качества общего характера, то есть умение отстаивать свою точку зрения, настаивать на решениях, защищать позицию и искать компромиссы между сторонами.
Каким образом можно попасть на должность системного архитектора?
Добро пожаловать в профессию
Высшее образование в нынешнее время не во всех ситуациях является определяющим требованием, но специальное техническое точно может оказаться полезным. Больше всего внимание обращают именно на практические умения и понимание работы в целом. Очень часто компании выбирают на эту должность именно тех сотрудников, которые имеют опыт работы с подобными проектами. Или вовсе повышают сотрудников, которые уже работает в данной компании, так как им проще будет руководить, опираясь на уже имеющиеся знания о проекте.
Существует ли на этой должности «карьерная лестница»?
В рамках самой работы главным инженером проекта может только возрастать объёмность и сложность проектов, а соответственно и оплата. Но сама по себе подобная работа позволяет набрать достаточно опыта в любом направлении, которое будет интересно, за счёт того, что приходится следить и организовывать совместную работу многих отделов проекта, попутно в ней участвуя. Набрав нужных знаний и получив достаточно навыков можно выбрать любое направление в IT сфере и развиваться в нём дальше.
Сколько зарабатывают системные архитекторы?
Это вопрос, который наверняка волнует любого человека, ведь сама по себе работа весьма непростая, а значит и заработная плата должна быть соизмеримой. На следующем скриншоте вы видите выдачу четырех последних загруженных вакансий на Headhunter по Москве. Если же самому заглянуть на сайт, то вряд ли вы найдёте зарплату меньше 150 тыс. р., а основная масса компаний предлагает зарплату в районе 300-400 тысяч. Немногие вакансии в IT сфере могут так же хорошо оплачиваться, как системный архитектор.
Сравнить, допустим, можно с PHP-разработчиком, чья оплата труда в среднм составляет 150-200 тыс. рублей. Как другой пример можно взять должность технического директора,
также посмотрев вакансии по Москве, чья зарплата начинается от 5 тыс. долларов, но которая относится к высшему менджменту и требует участия во всех до единого технических процессах.
Откликаются на эти вакансии не так много соискателей, в некоторых случаях можно вполне себе оказаться первым, и всё потому, что у многие разработчики не имеют достаточного опыта и навыков, чтобы к тому же быть ещё и человеком, понимающем в бизнесе. Опытных архитекторов тоже не хватает, для того, чтобы была сильная конкуренция на данную вакансию.
Вместо заключения
Системный архитектор — это один из самых важных участников IT-инфраструктуры, отвечающий за большое количество технических процессов. Без его организационной работы зачастую не представляется возможным довести проект за конца.
Для этой работы вы должны уметь работать в рамках всех других должностей. Тяжёлые проекты позволяют быстрее построить свою карьеру, но зачастую излишне напряжённая работа приводит к выгоранию.
Если устали работать руками, «нажимая кнопки» и готовы взвалить на себя ответственность за себя и того парня, то это то, что вам нужно. Это работа неплохо нагружает «технический склад ума», а также позволяет проявить творческий подход к проекту, общаясь с профессионалами и большими начальниками, а то и мир спасая от какого-нибудь техно-краха. Если всё это вам близко и подходит, дерзайте. Проявляйте инициативу, развивайте кругозор и интересуйтесь «железом» во всех его проявлениях и смыслах. Ведь за вычислительными системами — весь современный мир и будущее!
«Вместо заключения» — Задачи и понимание должности системного архитектора отличается от компании к компании. Узнать, какие задачи выполняет архитектор в Timeweb и чем это отличается от CTO и тимлида можно в новом выпуске подкаста:
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)
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) — это четко определенная практика постоянного (вечного!) проведения анализа, проектирования, планирования и реализации предприятия с использованием комплексного подхода в целях успешной разработки и реализации стратегии.
Определений ЕА существует так много и таких разных, что говорить об ЕА — как о чем-то однозначном — бессмысленно.
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: «главное поймите — у вас же специфика! Вам подойдет только эксклюзив, нужна кастрюлька (ЕА) уникальная и неповторимая»:
Где посмотреть полноформатную целостную ЕА на каком-либо фреймворке или без него? Хоть на одном А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
2.2 Laws of #BPM (Business Process Management)
improving-bpm-systems.blogspot.ru/2015/07/laws-of-bpm-business-process-management.html
Родственные направления алхимии местами переплетаются. Отличить где кончается BPM и начинается ЕА – очень сложно. Поэтому и мифы у них идентичные, алхимия же.
Каждый поставщик BPM (ЕА), каждый консультант BPM (ЕА), каждый «свод знаний» BPM (ЕА) (“body-of-knowledge”), каждая методология и фреймворк, и каждый клиент BPM (ЕА) понимают BPM (ЕА) по-разному. Это отличительная особенность любой алхимии.
Правильно сделанный BPM — это 50% Enterprise Architecture (EA).
Видимо верно и наоборот: Правильно сделанная ЕА – это 50% BPM.
Вообще странно, что не учитывает ВРМ по сравнению с ЕА? Что можно рассматривать ВРМ без оргштатной структуры, без входов и выходов процессов?
Любая «динамика» в ЕА – это уже и есть процесс, т.е. ВРМ. А в ВРМ задают и описывают всё связанное с процессом. Фактически любой жизненный цикл любого объекта или артефакта – это связь его состояний через процессы, т.е. направления переходов (из одного состояния в другое).
Особенно сложно для понимания являются встречающие в одном месте: Управление «архитектурой предприятия» и управление бизнес-процессами (BPM) предприятия. Типа «управление архитектурой» и «управление процессами», при этом «архитектура данных» и другие «суб — архитектуры» могут произвольно упаковываться сразу в оба указанных контейнера.
Проблемы 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, имеющих ценность для бизнеса.
«К сожалению, EA часто является синонимом практики документирования взглядов одного человека на ИТ их компании, — сетует Гриси.
Подчеркиваю: именно на ИТ, именно на документирование и именно лишь субъективизм архитектора. Такой подход вообще должен был погибнуть изначально.
По – хорошему, «ЕА – как алхимии» — давно должен был настать конец, но сегодня это очень хороший сегмент бизнеса, где главное не результат (где он?), а «сам процесс» (классический лозунг ВРМ). ИТ-Волшебники с биркой «ЕА-консалтинг», практически из ничего научились добывать золото: высокодоходный бизнес по консалтингу ЕА. Классическим алхимикам до такого «мастерства» было далеко.
Поэтому в статье и использован негативный окрас к подобному консалтингу: чаще всего пришлые профессиональные архитекторы знают (подозревают) о лженаучности применяемых подходов, но, подобно фокусникам, «выполняют свою работу» и в тайне держат статистику неуспешности и сами «фокусы»: не классические фреймворки (они публикуются), сколько искусство манипулирования ими и сознанием заказчика.
Следовательно, можно дать еще одно определение, 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 Мягкая критика
В интернете уже давно и много «мягкой» критики (см. гугл) современных и совсем не современных подходов к ЕА, только «точка кипения» еще не наступила, возможно, потому что «очень многие оказались в деле \ в доле».
Много из того, что выше было сказано, повторяется в блогах западных критиков, правда в смягчённых формулировках, возможно потому, что свой хлеб они зарабатывают на этом самом ЕА.
Странно, что подобной критики в рунете не нашел. Это говорит или о том, что в отличие от западного опыта, в России большинство проектов ЕА — успешные (на удивление всем нам и зависть буржуям) или об уровне зрелости отечественного образования по ЕА. Склоняюсь ко второму варианту.
Если мы говорим не об алхимии, то должен быть взят на вооружение принцип: «несомненнымъ является существование только нашего мыслящаго „я», существование же всего остального должно быть подвергнуто сомнению».
3 Конкурс на описание «household architecture»
Предлагаю начинающим и маститым архитекторам любых ЕА-конфессий составить описание архитектуры своего домохозяйства: «household architecture». Это будет лучшее подтверждение, что «Enterprise architecture» в их понимании имеет право на существование.
Надеюсь, что архитекторы согласятся, что домохозяйство имеет архитектуру и, что «household architecture» (HA) может быть представлена на базе известных подходов к описанию ЕА. Также надеюсь, что при описании своей HA, никому не понадобится NDA для супруга.
Условия участия простые: архитекторы подробно показывают свою «household architecture», рассказывают, как они ее строили и дают ссылки на используемый framework. Впрочем, можно привести любую другую «простую архитектуру» «простого предприятия»: детского сада, киоска «мороженное» и т.п.
Будет еще лучше, если:
А) архитекторы будут приводить несколько архитектур НА, указывая на их архитектурные отличия;
Б) описание одной и той же НА покажут на разных подходах, методологиях описания, фреймворках.
Ссылки на описания НА даем в комментариях к этой или к следующей главе (статье). В ней, в свою очередь, опубликую свое видение НА. Голосованием определим самую «правильную», наиболее «архитектурную» архитектуру домохозяйства. Оповестите знакомых архитекторов (включая ЕА, SA, IA и других хА), дайте им возможность внести посильный вклад в развитие ЕА \ НА. Месяца нам — архитекторам на это хватит? Задача то не архи-сложная.
Итак, писатели статей про ЕА, особенно живущие на хабре, – присылайте свои НА \ ЕА. Скромничать не нужно: думайте, рисуйте, «архитектурьте». Зачем рассуждать о сложном ЕА, давайте поговорим о простом НА.
‘Non-alchemysts’ aller Länder, vereinigt euch!
Представьте, какая досада охватит многих алхимиков, когда: