Enterprise Architecture vs алхимия предприятия. Часть 2. Проще некуда: простой фреймворк и простое предприятие



    Продолжаем популяризацию направления «Архитектура предприятия» и робкие попытки очищения его от алхимии и наукообразия. Начало: «Enterprise Architecture vs алхимия предприятия. Ключевые мифы»

    Наш подход к изучению — классический: от простого к сложному. Начинаем с самого простого: самого простого фреймворка – таблички Джона Захмана и самого простого предприятия – домохозяйства. Проще некуда. Соответственно, на выходе должна получиться самая простая «Архитектура предприятия». Не так ли?

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

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

    На мой взгляд, подобная тема – отразить собственную НА по какому-либо существующему «классическому» фреймворку или оригинальной методе описания ЕА, — прекрасная тема как для дипломных работ по специализации Enterprise Architecture специальности «Бизнес-информатика», так и возможность практикующим консультантам показать, насколько они знают толк в консалтинге ЕА.
    Надеюсь, что URL ссылка на свою НА (или эталонную) станет обязательным реквизитом квалификационной работы и визитки консалтера по данному направлению.


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

    Так вышло с табличным Mendeleev Framework: «Очевидно, я увидел во сне таблицу, в которой элементы были расположены по мере необходимости. Я проснулся и сразу же записал данные на листе бумаги и снова заснул. И только в одном месте потребовалась затем правка». Правда, Менделеев уточнил: «Я над ней, может быть, двадцать лет думал, а вы думаете: сидел и вдруг… готово».

    Примеров от «профессиональных архитекторов» нам, похоже, увидеть не придется. Профессиональная «Алхимия, все-же»: «профессиональный» кодекс «матерого» алхимика запрещает публикацию как «Enterprise Architecture example», так и своих личных НА.
    Для них это, видимо, равносильно харакири: мужественно, но трагично. За подобные откровения они рискуют потерять статус «великого гуру» и будут названы предателями и болтунами, не обеспечившими должной защиты Enterprise Voodoo.

    Цифровой век, постиндустриальная эпоха, нанотехнологии … Может и так, но есть еще отличительные особенности нашего времени – это век маркетинга и «управленческих уловок» (management fad), возрождение эпохи алхимии и их совместная победа над здравым смыслом.

    Начнем повествование «с чего начать» свои первые зарисовки НА. Какие сущности отобразить в описании своей НА: What? С помощью чего и как отобразить: How? Что это будет за описание: в виде обычных букв (текста), структурированного языка, таблицы или диаграммы?

    Джон Захман считается «отцом ЕА», поэтому начнем с краткого описания его таблички: Zachman Framework (ZF). Четвертый раздел знакомит с этим старинным фреймворком, отвечая на вопрос «как отобразить, в какой форме».

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

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

    4 Zachman Framework


    www.zachman.com — The Official Home of Zachman International and the Zachman Framework
    уже не отвечает. Странно это. Есть ли зеркала? «.net» — тоже молчит.
    Есть еще: Zachman Institute for Framework Architecture но это (видимо) лишь инструмент монетизации.
    Совсем уныло у нашей Вики:
    Куда лучше у ненашей Вики:
    en.wikipedia.org/wiki/Zachman_Framework
    en.wikiquote.org/wiki/John_Zachman
    Однако Вики не показывают хронологию в артефактах, а нам важен «дух», содержащийся в первоисточниках (которые видимо были на www.zachman.com ?).

    За основу возьмем информацию от dragon1
    и The Zachman Framework Evolution (Part 1)

    Напомним, что большинство (а может и все) известных описаний структур, «каркасов», подходов к описанию, принципов, каркасных методологий и т.п. (фреймворков) были созданы именно под описание ИТ-архитектуры, архитектуры информационных систем. Изначально, что 1984- ом, что в 1987- ом, что в 1992-ом, «отец ЕА» давал именно такие имена (названия): «A framework for information systems architecture».

    Т.е. J. A. Zachman использовал название ISA framework (information systems architecture), а применение матрицы планировалось как совершенствование методики IBM BSP. Про планирование бизнес-систем (Business System Planning, BSP) компании «Международные бизнес-машины» (International Business Machines, IBM) уже давно никто не вспоминает.

    4.1 Хронология рамочных табличек Захмана


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

    Июнь 1984, Zachman84




    1984, Zachman84v2


    THE ZACHMAN FRAMEWORK EVOLUTION BY JOHN P ZACHMAN


    1987, Zachman87 (5х3)


    Первая статья Захмана: Zachman J. A. A Framework for Information System Architecture // IBM System Journal. 1987. Vol. 26, No. 3.

    Как видим все три таблицы ZF фактически идентичны.

    1992, Zachman92 (5х6)


    Точнее это фреймворк «Сова – Захман»: Sowa J. F., Zachman J. A. Extending and Formalizing the Framework for Information System Architecture // IBM Systems Journal. 1992. V. 31. № 3.
    www.jfsowa.com/pubs/sowazach.pdf
    Хотя чаще под Zachman92 приводят картинку ниже:


    Откуда эта картинка, не нашел, т.к. Zachman .com / .net не отвечают, а именно туда ведут основные ссылки.
    Первые три колонки взяты из предыдущих версий и добавлены еще три колонки справа.

    Zachman2k




    Zachman etc
    Иногда упоминают Zachman93, 04, 08, 11, но это фактически тот же Zachman2k, а все фреймворки с 1993 года — уже как бы «ЕА».
    Считается, что версия №2 датирована 2008 годом, а текущая версия фреймворка №3 2011: ZachmanV3 (ZFv3)

    Иногда вместо матрицы 5х6 упоминают 6х6, т.е. не 30 ячеек Захмана, а 36, что не принципиально, т.к. одни считают последнюю строку за значимую, другие нет, так же, как и не считают нулевую строку (шапку таблицы).

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

    4.2 Что? Где? Когда?


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

    Иногда изначальный порядок следования вопросов меняют и первой колонкой ставят последнюю: «Зачем?», тем самым, подчеркивая главенство «списка целей» и «стратегий бизнеса».

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

    Этапам соответствуют «перспективы» (точки зрения на объекты и процессы): планировщик, собственник, проектировщик (дизайнер), разработчик, подрядчик.
    Кто такой Planer? Планёр? Планировщик? Стратег? Главный архитектор?
    Кто такой Owner? Владелец чего? Хозяин, акционер? Зачем ему Модель бизнес-процессов? Видимо это Владелец(ы) бизнес-процессов? А кто он(и) в компании? Уж точно не акционер (он и слов то таких может не знать).

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

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

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

    Форма Zachman Framework является матрицей 5х6 (6x6), где каждая ячейка содержит набор диаграмм. Матрица выполнена как отчет, позволяющий визуализировать, какая информация доступна на каком уровне (в каком разрезе) на конкретном предприятии.

    Структура таблички (фреймворк) Захмана позиционируется как одна из Enterprise Ontology: “учение о сущем” (инструмент мышления), определяющая фундаментальные принципы устройства предприятия, сущностные формы, ключевые элементы и свойства.

    Такая «Онтология предприятия» претендует на самостоятельное научное направление в рамках computer science & engineering, включая, исследование понятийного аппарата и разработка на его основе классификатора с табличной структурой, позволяющего анализ критериев и моделей проектируемого объекта (предприятия). Она считается отраслевым стандартом в ИТ.
    Подробнее читаем:

    Лекция 8: Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF (ссылка на ИНТУИТ удалена по требованию модератора)
    или тут
    или здесь

    Однако вразумительных разъяснений (для «чайников») ключевых идей Zachman Framework я не нашел (или их не понял).
    Конечно, табличка интуитивно понятна, но как ее использовать на практике?
    Также нет методики заполнения таблицы и самих примеров. Однако, уверен, что учебные пособия по табличке Захмана отечественных ВУЗов не вызывают ни у кого сомнения и студенты получают свое твердое «отлично», лишь за «честно вызубренную» алхимию по ЕА.

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

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

    4.3 ISA vs EA


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

    Принято считать, что название «Архитектура предприятия» стало популярным после публикации книги Стивена Спивака (тоже из IBM), описывающей процесс «Планирование архитектуры предприятия» (Enterprise Architecture Planning, EAP), после чего и Захман стал применять именно это название.
    Spewak S. H., Steven C. Hill. Enterprise Architecture Planning: Developing a Blueprint for Data, Application and Technology. NY: John Wiley & Sons Inc, 1992.

    На основе этого, в последующем произошло еще что-то более странное, в результате чего «Корпоративная архитектура» – как совокупность архитектур: «Бизнесовая» – «Технологическая» – «Инфраструктурная» (включая ИТ-архитектуру), свелась лишь в ИТ-архитектуру, выдаваемую за ЕА.
    Таким образом, «архитектура информационных систем» получила новое «более громкое» имя «Архитектура предприятия». Это была блестящая победа «management fad» над здравым смыслом.

    Чтобы как то «смягчить» такую подмену, иногда употребляется фраза, что существующие фреймворки ЕА являются «ИТ-ориентированными». Таким образом, в 1993 произошла сомнительна трансформация табличного фреймворка Захмана от ISA к EA, а вслед за этим воцарилась гегемония ИТ над архитектурным описанием предприятия (современное понимание ЕА). Отсюда и ввел дату 1993-2018 на заставке к статье «Alchemy International».
    Про историю возникновения термина ЕА и историю фреймворков можно почитать:
    The History of Enterprise Architecture: An Evidence-Based Review

    Там делается вывод, что всем основополагающим идеям, составляющим современную концепцию EA, уже 50 лет.
    Т.е. маркетинговая индустрия половину столетия успешно продает «одно и то же», но под разным «соусом». Кстати Джон Захман работал в IBM специалистом по маркетингу (Marketing Division of IBM).

    Фундаментальная структура
    Институт Захмана (ZIFA) утверждает: «есть реальные доказательства того, что наша структура является фундаментальной структурой для архитектуры предприятия.
    Таким образом, он дает полный набор описательных представлений, применимых для описания предприятия".
    Не видел таких доказательств, где они, где примеры Zachman Framework example?

    Ах, да забыл: это же NDA, ДСП, военная тайна, Х-Files и другие «отмазки» консалтеров по маскировки алхимии под науку. Обсуждение с конца 70-х действительно популярной таблички Захмана так и не принесло массы публикуемых примеров ее заполнения по конкретным предприятиям. Зато успехи в маркетинге – впечатляющие.

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

    Соответствующий запрос в гугл по вкладке «картинки» должен был выплеснуть массу конкретных e.g. реальных предприятий, но там этим вообще и «не пахнет».
    Однако, в основном наблюдаю разговоры о практической ценности таблицы Захмана, включая даже сопоставление ее значимости для человечества (важности) с периодической таблицей Менделеева. Это в то время, как конкретных примеров заполнения таблицы нет, т.е. описания опытов и их анализ отсутствует как таковой, нет и методологии заполнения таблицы.

    Табличный каркас (фреймворк) Захмана позиционируется только «лишь фреймворк», но никак не методология (в отличие, например, от ТОГАФ), т.к. в нем не говорится: как делать, а только представлен шаблон «куда вписывать проектный артефакт», т.е. сортировать их по ячейкам таблицы.

    Ограниченность подхода дает «веский аргумент», который также заимствован другими фреймворками и методологиями ЕА, включая ТОГАФ: «если у Вас получилось хорошо, значит — это заслуга нашего фреймворка, а если плохо, то фреймворк не виноват, — это у Вас руки кривые». Попробовали бы они подобное сказать применительно к Mendeleev Framework: химия – это вам не алхимия.

    Framework for household architecture
    Для описания своей НА не обязательно пользоваться каркасной табличкой Захмана, она приведена лишь как один из примеров, прежде всего потому, что это первое что приходит в голову для формализации НА.
    Есть сомнение, что и другие фреймворки и методологии окажутся более эффективными, в первую очередь потому, что они не ЕА, а лишь ISA (но упорно выдаваемые за ЕА). Есть ли фреймворки, ориентированные на предприятие, а не на его ИТ? Вопрос открытый.

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

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

    5 Введение в объект домохозяйство


    5.1 Household


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

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

    5.2 Основы учета


    Много статей про финансовый учет в домохозяйстве. Например, на хабре из «свежего»:
    История о появлении финансового учета в моей жизни
    Финансовый учет для не предпринимателей
    Личная система управления финансами
    Удивительно, но почти то же самое рассказывал … и Николай Васильевич Гоголь в своих «Семь куч». Краткие отрывки из Советов Гоголя по ведению хозяйства: «Семь куч», как один из типов архитектур финансового управления домохозяйства.

    «Разделите ваши деньги на семь почти равных куч.
    В первой куче будут деньги на квартиру, с отопкою, водой, дровами и всем, что ни относится до стен дома и чистоты двора.
    Во второй куче — деньги на стол и на все съестное с жалованьем повару и продовольствием всего, что ни живет в вашем доме.
    В третьей куче — экипаж: карета, кучер, лошади, сено, овес, словом — все, что относится к этой части.
    В четвертой куче — деньги на гардероб, то есть все, что нужно для вас обоих затем, чтобы показаться в свет или сидеть дома.
    В пятой куче будут ваши карманные деньги.
    В шестой куче — деньги на чрезвычайные издержки, какие могут встретиться: перемена мебели, покупка нового экипажа и даже вспомоществование кому-нибудь из ваших родственников, если бы он возымел внезапную надобность.
    Седьмая куча — Богу, то есть деньги на церковь и на бедных.

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

    Какие ни представлялись бы вам в это время выгодные покупки и как бы ни соблазняли они вас своею дешевизною, не покупайте. На это можете отважиться потом, когда побольше укрепитесь».

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

    и пример из «Личная система управления финансами» («двухмесячного накопления»):
    «Например, Вы хотите купить что-то за 20000 рублей (или другую сумму, за которой не надо идти в банк и брать кредит). А Ваш «такт» это 10000. Заведите отдельный целевой счёт (или откройте новую литровую банку), и в течение двух месяцев переведите туда эти 20000. Если к этому времени желание купить этот товар не пропало, значит, он действительно нужен. Это позволит избежать импульсивных больших трат».

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

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

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

    5.3 Артефакты и ментальные заменители


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

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

    С позиции CMMI это видимо будет считаться самым низким уровнем зрелости управления «предприятия» типа домохозяйство, т.е. Initial (Начальный, «Хаос», «Анархия»)

    Но в рамках домохозяйства это, как правило, работает и действительно не требует формализации на бумажном носителе, т.к. эффективные инструменты «кнута и пряника» обычно помогают быстро усвоить «семейную конституцию» и хранить ее в ОЗУ черепной коробки с обеспечением Continuous Availability.

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

    5.4 Учет бизнес-процессов


    Формализованного Каталога бизнес-процессов домохозяйства, как правило, нет, впрочем, как и формализованного Каталога продуктов и услуг НА. Реестр, список важных процессов опять же держится в голове. Правда иногда по отдельным наиболее критичным процессам возникает острая необходимость его не только составления, но и «публикации» прямо «на выходе» — путем приклеивания листочка к дверной двери.

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

    5.5 Продукты


    Речь не о продуктах питания и отходах. Каждый объект типа «предприятие» вырабатывает некий продукт, который востребован другими объектами и субъектами. При этом «продуктовый» бизнес-процесс имеет выход в качестве «продукта» или услуги. Какой в Вашем домохозяйстве «Каталог продуктов и услуг»? В терминах «продуктов» и «услуг».

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

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

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

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

    6 Некоторые особенности Архитектурики ЕА


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

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

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

    Важен не столько сам термин, главное четко определиться, что он означает и подчеркнуть, что это «межотраслевой» термин: зодчество — строения, электроника — процессоры, экономика – предприятия и другие отраслевые аналогии.

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

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

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

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

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

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

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

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

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

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

    Иногда происходит смешение понятий, когда один и тот же предмет рассматривается в разных значениях. Например, «архитектура города» — действительно дает разночтение. Какой объект рассматривается?
    Если объект «градостроительство», то да, родственное «архитектура зодчества». Застройка города: точечная, комплексная, tower city и т.п. Пример из гоголевской архитектурики:

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

    Заключение


    Проще «пареной репы»: простейший фреймворк и простейший объект исследования – домохозяйство, следовательно, должна получиться простейшая «household architecture» (НА). Информации как по табличке Захмана, так и внутренней механики домохозяйства – море, а «практика жизни» позволяет соотнести архитектору теоретические выкладки со своим собственным опытом (присутствие в мире домохозяйства).

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



    Colorama for Enterprise Architect (ZF compatible)

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

    «Маркетинг против науки» и «300 процентов по-Марксу» – вот ключевые факторы царства и общественного почитания околонаучных рассуждению вокруг ЕА и маскировки алхимии под «Best Practice».

    Revenons a nos moutons: пока статистика по конкурсу не радостная, к моменту публикации этой статьи получено 0,0000 описаний НА. Такими темпами алхимию не побороть.
    Возможно, профессиональным корпоративным архитекторам «неприлично» описывать архитектуру домохозяйства (профессиональная этика), но хоть кто-то надеюсь «снизойдет» и покажет «мастер класс» начинающим?

    Девиз: Отключи алхимию, включи сознание и нарисуй архитектуру своего домохозяйства!

    Ваш, bipiem

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Почему не участвую в конкурсе на описание «household architecture»
    Поделиться публикацией

    Похожие публикации

    Комментарии 60
      +1
      Для предметного анализа архитектуры, нужно привести описание (характеристику) самого объекта архитектурья: домохозяйства. Как бы нам не казалось, что ничего сложного в нем нет. Домохозяйство — это, прежде всего, экономический субъект экономики (экономическая сущность).

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


      Тем не менее, Устав в качестве документа с признаком «ментальный» указываем в списке «Ключевых вещей НА».

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


      Ключевым элементом НА будет архитектура его бизнес-процессов.

      Что такое "архитектура бизнес-процессов"?


      Каждый объект типа «предприятие» вырабатывает некий продукт, который востребован другими объектами и субъектами. При этом «продуктовый» бизнес-процесс имеет выход в качестве «продукта» или услуги. Какой в Вашем домохозяйстве «Каталог продуктов и услуг»?

      Никакого. Мое домохозяйство — не предприятие.


      Важен не столько сам термин, главное четко определиться, что он означает и подчеркнуть, что это «межотраслевой» термин: зодчество — строения, электроника — процессоры, экономика – предприятия и другие отраслевые аналогии.

      Ура. Можно, пожалуйста, наконец, услышать определение? Раз уж вы сказали "главное четко определиться"?


      Ой, кажется, нет.


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

      Что-то в прошлый раз вы так и не смогли показать эталонной архитектуры храма. Можно в этот раз на нее посмотреть?


      пока статистика по конкурсу не радостная, к моменту публикации этой статьи получено 0,0000 описаний НА. Такими темпами алхимию не побороть.

      Ну, вы с себя-то начните? Вы ввели понятие household architecture, вам и показывать первый пример.

        –1
        Меня мучает вопрос: если Вас не интересуют ЕА \ НА (архитектуры, архитектурные стили, фреймворки, предприятия),

        то зачем Вам тратить драгоценное время на «ненужное Вам»?

        Вы ввели понятие household architecture …

        household architecture принципиально ничем не отличается от Enterprise Architecture, это всего лишь особый тип предприятия. Консалтеры ведь любят продавать Enterprise Architecture под «гос-управление» (FEAF и др.), т.е. от «масштаба предприятия» к «масштабу государства».
        В случае с НА – наоборот:
        ДОМАШНЕЕ ХОЗЯЙСТВО — один из трех основных субъектов экономической деятельности
        (государство, предприятия, домашние хозяйства). Райзберг Б.А., Лозовский Л.Ш., Стародубцева Е.Б… Современный экономический словарь. — 2-е изд., испр. М.: ИНФРА-М. 479 с… 1999.

        Это ответ и к
        Вообще, занятно. Вот вы пишете:


        … вам и показывать первый пример.

        Пример покажу (ведь «продолжение следует»). Насчет «первым» — не уверен.
        Хочется верить, что «Время первых» в стане не «кануло в Лету» и профессионалы, зарабатывающие свой «хлеб» на Enterprise Architecture, окажутся впереди меня.
          0
          то зачем Вам тратить драгоценное время на «ненужное Вам»?

          Duty Calls


          household architecture принципиально ничем не отличается от Enterprise Architecture, это всего лишь особый тип предприятия.

          Если трактовать household как особый тип предприятия.


          ДОМАШНЕЕ ХОЗЯЙСТВО — один из трех основных субъектов экономической деятельности

          Это термин в рамках экономики (да, вы опять совершаете ту же самую ошибку). Но, во-первых, почему вы считаете, что единственно правильный перевод household — это "домашнее хозяйство", и, во-вторых, почему вы считаете, что нужно брать термин именно из экономики? В экономике ведь нет понятия "архитектура", значит, вы в рамках этой дисциплины не останетесь.


          И это естественным образом возвращает нас к вопросу целей.


          Хочется верить, что «Время первых» в стане не «кануло в Лету» и профессионалы, зарабатывающие свой «хлеб» на Enterprise Architecture, окажутся впереди меня.

          … а зачем им это?

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

            Есть. Когда говорят о трех основных субъектах экономической деятельности: государства, предприятия, домохозяйства, то уже подразумевается «трехуровневая архитектура экономики» (экономической деятельности). Это очень упрощённый ответ.

            … а зачем им это?

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

              Я вот не поленился и пошел в Яндекс.


              архитектура в экономике
              трехуровневая архитектура экономики


              Так что нет такого понятия. Вы его придумали на ходу (или нашли что-то, что вы считаете подходящим). Но в терминологической системе такого понятия нет.


              Как вариант, «Потренироваться»: ведь указанные в статье вопросы, надеюсь, будут задавать на их тренингах и курсах.

              Вы считаете, что ваша задача представляет для человека, который уже имеет опыт в этой области, тренировочный интерес? Я вот на нее смотрю, прищурившись, и мне кажется, что это что-то навроде "опишите архитектуру консольной утилиты" для архитектора ПО: можно, но зачем?


              Могут быть разные причины, от любопытства и поиска истины

              … поиска какой истины? О чем?

        +1

        Вообще, занятно. Вот вы пишете:


        На мой взгляд, подобная тема – отразить собственную НА по какому-либо существующему «классическому» фреймворку или оригинальной методе описания ЕА, — прекрасная тема как для дипломных работ по специализации Enterprise Architecture специальности «Бизнес-информатика», так и возможность практикующим консультантам показать, насколько они знают толк в консалтинге ЕА. Надеюсь, что URL ссылка на свою НА (или эталонную) станет обязательным реквизитом квалификационной работы и визитки консалтера по данному направлению.

        Но сам ничего подобного не показываете.


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


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

          –1
          Но сам ничего подобного не показываете.

          Напомню «красную нить» статьи: На протяжении полувека НИКТО и НИЧЕГО не показывает и
          «Enterprise Architecture example» = 0 (или «почти равен»)
          Чтобы это поломать — и задуман цикл статей.
            0
            Напомню «красную нить» статьи: На протяжении полувека НИКТО и НИЧЕГО не показывает и
            «Enterprise Architecture example»

            Так вы же тоже ничего до сих пор не показали. У вас большой текст из общих рассуждений и метафор, и никакой конкретики. Наоборот, вы предлагаете читателю самостоятельно подумать над «архитектурой домохозяйства», и предлагаете как возможный вариант ему также самостоятельно разобраться с каким-то фреймворком, с которым вы по вашим же словам и сами не слишком разобрались.
            Или вы хотите в самом конце цикла конкретны примеры приводить? Так читатели же не дотерпят.
              –1
              Или вы хотите в самом конце цикла конкретны примеры приводить? Так читатели же не дотерпят.

              Куда торопиться? За 50 лет революционных изменений в этом направлении не было.

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

              Да, «думать» в России разучились и созидать тоже («большое спасибо» углеводородам). Поэтому, как Вы и сказали: предлагаю именно «подумать» и именно «самостоятельно». Почему методологии ЕА не отечественного производства, где импортозамещениЕ?

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

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

                Ну, вы по себе-то (а по кому еще?) не судите.


                Почему методологии ЕА не отечественного производства, где импортозамещениЕ?

                А зачем? Как вообще можно "импортозаместить" методологию? В отличие от производства и разработки, идеи международны изначально.

                  0
                  Ну, вы по себе-то (а по кому еще?) не судите.

                  Я делаю вывод «разучились созидать» на основе объективности: вокруг меня исключительно товары импорта: айфончики, вычислительная и сетевая техника, машины и авиалайнеры. Это о многом говорит.

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

                  Как раз методологию и нужно импортозамещать в первую очередь. Только с поправкой: научную методология. Алхимию импортозамещать действительно не нужно.
                    +2
                    Я делаю вывод «разучились созидать» на основе объективности: вокруг меня исключительно товары импорта: айфончики, вычислительная и сетевая техника, машины и авиалайнеры.

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


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

                    Может быть это потому, что "исключительно национальные" идеи никому не нужны, на самом деле?


                    Как раз методологию и нужно импортозамещать в первую очередь. Только с поправкой: научную методология.

                    Как вы себе представляете импортозамещение научной методологии? Вот есть фальсификационизм, как его "заместить"?

                  +1
                  C ZF считаю, что разобрался и сделал в статье вывод, что это еще «вещь в себе» и ее практическое применение очень условно, т.к. этот фреймворк несет лишь некие общие тезисы, упакованные в структурированную форму – табличку.

                  Хорошо, но зачем тогда вы тратили свое и наше время, описывая эту «вещь в себе»?

                  Да, «думать» в России разучились и созидать тоже («большое спасибо» углеводородам).

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

                  Поэтому, как Вы и сказали: предлагаю именно «подумать» и именно «самостоятельно».

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

                Тот самый, в котором вы тоже ничего не показываете?

              +1
              del
                0

                Читал с надеждой увидеть хоть какой-то список действий (фреймворк) для описания HA, но только рассуждения про HA и утверждения что это почти тоже, что и EA.


                А вот если мне нет необходимости детально разбираться в EA, а формализовать HA хочется, как быть простым "смертным"?


                PS
                Если выдвигается утверждение, что надо прикладывать ссылку на HA, то было бы неплохо иметь HOW TO, чтобы можно было делать это всем.

                  0
                  Вы правильно говорите.
                  Однако, начинаем с рассуждений. Авангард должны составить онтологи-созидатели, далее «протоптанной тропой» «простые смертные» смогут строить свои НА, ЕА или даже «федеральные архитектуры» по простым методичкам.

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

                  Неужели «простым смертным» не интересно попробовать внести свой вклад в становление этого направления? Речь о «ЕА открытом и применимом на практике» не его маркетинговых уловках.

                  Тем, кому «нет необходимости детально разбираться в EA, а формализовать HA хочется» придется немного подождать. Мы только начали.
                    +1

                    Если вы планируете делать цикл статей, то было бы не плохо, в начале делать вступление о чем будет этот цикл и о чем текущая статья. А не обнадеживать "простых смертных" фреймворками хотя бы для HA.


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

                      –1
                      Если вы планируете делать цикл статей, то было бы не плохо, в начале делать вступление о чем будет этот цикл и о чем текущая статья.

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


                      А не обнадеживать «простых смертных» фреймворками хотя бы для HA.

                      Я призываю их подумать и поучаствовать в апробации существующих фреймворков или формировании новых.
                      Мне пока сон с «идеальным фреймворком» не приснился. Что такой фреймворк существует, но до сих пор не опубликован — у меня сомнений нет.
                      Подчеркиваю: «проще простого» — берем самый простой ZF и свою же родную организацию – домохозяйство и далее пытаемся сделать действия, которые алхимики преподносят как научные методы.

                      Опыты или должны быть успешными или доказана не научность подходов, т.е. перенос этих «знаний» из области «computer science & engineering» в область «alchemy & voodoo».

                        0

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

                          0
                          Если кто-то сделал подобное лучше меня: коротко и понятно – буду только рад. Ссылка есть?
                            0

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


                            PS
                            Хотя я могу быть в чем-то и не прав.

                              –1
                              И в вашей области я не знаю специалистов которые здесь публиковались,

                              Мне тоже хотелось бы их послушать. Молчат только они.

                              хочется больше конкретики или итеративности в разработке, чтобы было понятно что и как делать.

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

                              Год только начался: будет и конкретика и итеративность, только нужно для этого хоть что-то попытаться сделать самому.
                              Вы начали составлять описание своей НА? С чего начали?
                              Какой был Ваш ответ по опросу?
                                0
                                Но когда понял, что там этого нет и это все алхимия

                                Это, знаете ли, плохо сочетается с


                                Мне тоже хотелось бы их послушать.

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

                                  –1
                                  не обвиняют заранее и не вынуждают защищаться.

                                  Раздел 2.5 Первой статьи:
                                  Если мы говорим не об алхимии, то должен быть взят на вооружение принцип: «несомненнымъ является существование только нашего мыслящаго „я", существование же всего остального должно быть подвергнуто сомнению».

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

                                  Я не рекламирую альтернативные «консалтерские конторы», задача одна — разобраться и отделить «мух от котлет»: наука и инженерия отдельно от «alchemy & voodoo».
                                    +2
                                    Критика — вынужденная мера и исключительно в целях организации дискуссии

                                    "это все алхимия" — это не критика, в этом и проблема. Если бы ваш принцип был "существование всего остального должно быть подвергнуто сомнению", то надо сомневаться в существовани (а) архитектуры вообще как принципа (б) предприятий (ц) household architecture и (д) верности любого вашего обобщающего утверждения. Они же тоже все ничем не подтверждены.


                                    Но вы предлагаете строить некую household architecture, хотя ее существование ничем не подтверждено. Зачем?

                                      –1
                                      вы предлагаете строить некую household architecture

                                      Строим «классическую» (или хоть какую-нибудь, хоть в каком-то понимании) ЕА. Только Объект не «корпорация» или «МСБ», а – домохозяйство.

                                      хотя ее существование ничем не подтверждено.

                                      Существование Enterprise Architecture подтверждено? Чем? Горами чистого маркетинга? Пропагандой? Fake news?
                                        0

                                        Ну то есть вы предлагаете строить то, существование чего вы же считаете неподтвержденным?

                                  0

                                  Не начал.


                                  Какой опрос? Ни в одной из статей я опроса не видел? Или он по тексту?

                                    0
                                    Какой опрос? Ни в одной из статей я опроса не видел? Или он по тексту?

                                    Самый конец обсуждаемой статьи:
                                    Почему не участвую в конкурсе на описание «household architecture»
                                      0

                                      Ответ: не читал первую статью.


                                      И как видите, я ожидал рекомендаций в этой статье.


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


                                      Я так полагаю хотелось что-то в стиле open source сделать, но как-то мне кажется, сначала надо убедить (или даже создать) сообщество в необходимости всего этого, а потом привлекать других.


                                      PS
                                      И опросы принято делать в виде опросов, чтобы не искать их по тексту.

                                        0
                                        И опросы принято делать в виде опросов, чтобы не искать их по тексту.

                                        А с ним то, что не так? Поместил опрос в конец статьи (кнопка «Добавить опрос»), нужно было в начале (что не так)?
                                          0

                                          Вот теперь с ним все так.


                                          Ответ: Другое.


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


                                          А было бы описано в начале что, для чего и почему. Не тратил бы и время тогда...


                                          Но все равно спасибо за статью.

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

                    Кстати.


                    Mosque–Cathedral of Córdoba: Moorish, Renaissance
                    Mezquita-catedral de Córdoba: Islámico, Gótico, renacentista y barroco


                    Правда, поучительно? Или вот:


                    York Minster

                      0
                      Подходы к архитектурики зодчества мы с Вами детально обсудили в прошлой статье
                      «Enterprise Architecture vs алхимия предприятия. Ключевые мифы»

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

                      Детальный спор про архитектуру зодчества вне scope наших Enterprise Architecture & Household Architecture.

                      Задайте пожалуйста вопрос конкретно или по ZF или по «объекту архитектурья» (НА), т.е. по теме Enterprise Architecture (т.е. по теме статьи).
                        +1
                        Подходы к архитектурики зодчества мы с Вами детально обсудили в прошлой статье

                        Обсудить-то обсудили, но вы же продолжаете приводить эту некорректную аргументацию. Не вижу причин, почему я не могу ее оспаривать.


                        Детальный спор про архитектуру зодчества вне scope наших Enterprise Architecture & Household Architecture.

                        Тогда перестаньте приводить эти аргументы.


                        Задайте пожалуйста вопрос конкретно или по ZF или по «объекту архитектурья» (НА), т.е. по теме Enterprise Architecture (т.е. по теме статьи).

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

                      0
                      Абстрактное домохозяйство описывать смысла большого нет. Вот пример-черновик бизнес-архитектуры для общежития, которое в Википедии указано как вид домохозяйства. Связи, прости, не подписал. Сделал за 2 часа из спортивного интереса.

                        0
                        Спасибо большое.
                        В открытом доступе появился ПЕРВЫЙ пример Enterprise Architecture! Не верю своим глазам.
                        Вопросы: это точно Enterprise Architecture (предприятия типа «общежитие»)?
                        Видимо это часть ЕА, под названием «бизнес-архитектура»? Что к этой схеме нужно добавить, чтобы получилась полная Enterprise Architecture предприятия типа «общежитие»?

                        К какой нотации это нарисовано и на каком инструменте?
                        Можно какое-нибудь пояснение к схеме? Что на ней отражено?
                        Связи, прости, не подписал.

                        Какие примеры подписей к связям?
                        Может это что-то из области BPM? Может еще примеры есть?
                          0
                          Нужно добавить обеспечивающие слои (технически и физический), в качестве примера смотри дополнительную схему.
                          Нарисовано в инструменте Archi в нотации Archimate 3.
                          Изображен бизнес общежития по продаже мест для временного проживания и обслуживание этих мест. Дополнительно добавлены элементы мотивации, влияющие на бизнес.
                          Подписи (глаголы) читаются по направлению стрелок. Пример: исполняет, обслуживает, влияете, создает, содержит, состоит из, и др. Не типизированные ассоциации можно по-разному подписывать, желательно такие связи минимизировать.
                            0
                            Тут случайно 2 функции (внизу справа) сделал сервисами, исходная модель на другом компе осталась, то есть эту рисовал отдельно от первой.
                              0
                              Нужно добавить обеспечивающие слои (технически и физический), в качестве примера смотри дополнительную схему.

                              Какой слой показан? технический и физический?

                              Подписи (глаголы) читаются по направлению стрелок.

                              Как определить начало? Ромб это начало или конец стрелки?

                              Зачем все это придумали? Если более 20 лет назад то же самое рисовали в АРИС? Причем в куда более понятной нотации ЕРС чем эта.

                              Как то это мега нотация делится на под-натации?
                              Полагаю, что это под-нотация: ArchiMate «Business Layer Elements» (или более точное название?)
                              Table 6: Business Layer Elements
                              pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc489946048

                              И на одной схеме прямо — и тумбочки и продукт — все вместе? Это нормально?
                              ВСЯ ЕА на двух листах поместилась?
                                0
                                Какой слой показан? технический и физический?

                                Показаны слои бизнес и физические. (я кстати оговорился, не технический и технологический).

                                Как определить начало? Ромб это начало или конец стрелки?

                                Ромб это начало для агрегации и композиции.

                                Зачем все это придумали? Если более 20 лет назад то же самое рисовали в АРИС? Причем в куда более понятной нотации ЕРС чем эта.

                                То да, не то. Явно введено понятие сервис, связь между уровнями, другие моменты.
                                Я пока не буду проводить тут сравнение.
                                А так, EPC тоже хорошая нотация, мне нравится.

                                Как то это мега нотация делится на под-натации?

                                Да, не маленькая, но не сложнее, чем UML.

                                И на одной схеме прямо — и тумбочки и продукт — все вместе? Это нормально?

                                В этом отличие от других нотаций, где нужно под каждый аспект строить диаграмму, а потом еще трассировочную таблицу или гибридную диаграмму.
                                В результате получается множество диаграмм и таблиц, в которых начинается путаться сам автор.
                                А тут наглядно показаны и специфицированы связи, по ни видно:
                                1) Как устроен бизнес.
                                2) Как IT обеспечивает и реализует элементы бизнеса.
                                3) На каких технология реализован IT, и где развернуты IT элементы.
                                  0
                                  Ромб это начало для агрегации и композиции.

                                  Т.е. стрелка на конце линии — это конец линии, и ромб — это тоже конец линии.

                                  А так, EPC тоже хорошая нотация
                                  не сложнее, чем UML.

                                  Правильно я понял, что ЕРС, UML (а также, видимо workflow, BPMN и прочее) — в «топку» или на «свалку истории»: Да — здравствует новый король, встречаем супер-пупер нотацию ArchiMate!
                                  А тут наглядно показаны и специфицированы связи, по ни видно:
                                  1) Как устроен бизнес.
                                  2) Как IT обеспечивает и реализует элементы бизнеса.
                                  3) На каких технология реализован IT, и где развернуты IT элементы.

                                  Вы про две указанные Вами схемы?
                                  Так Вами была показана полная ЕА или нет?

                                  И Вы тоже примеров публикации ЕА не видели? Какое этому объяснение?
                                  Как по-Вашему, кто целевой потребитель описания ЕА? Кроме самого архитектора, конечно.
                                  Руководитель предприятия должен понимать рисунок ЕА своего предприятия?
                                    +1
                                    Т.е. стрелка на конце линии — это конец линии, и ромб — это тоже конец линии.

                                    Посмотрите тут Summary of Relationships
                                    Начало связи слева, конец справа. Читать нужно с «начала» в направлении «конца». Я только не понимаю, зачем Вы это спрашиваете. Вы написали много тут статей, и, вероятно, всё понимаете.

                                    Правильно я понял, что ЕРС, UML (а также, видимо workflow, BPMN и прочее) — в «топку» или на «свалку истории»: Да — здравствует новый король, встречаем супер-пупер нотацию ArchiMate!

                                    Конечно, нет. Форма Вашего вопроса не располагает меня к ответу. И, по всей видимости, правильный развернутый ответ Вы знаете.

                                    Вы про две указанные Вами схемы?
                                    Так Вами была показана полная ЕА или нет?

                                    Вам же говорили, что нет исходной цели для чего и для кого нужно описать HA. Не выбраны точки зрения (view points). «Полная» предполагает наличие некоторого критерия полноты — соответствие некоторым параметрам по ширине, глубине и доменам архитектуры. Посмотрите Scoping the Architecture.
                                    Я нарисовал пример-черновик. У Вас есть сомнения в том, что я смогу создать HA заданной полноты, если у меня будут четкие требования («Заявка на архитектурную работу»).
                                    Если Вам нужно другую архитектуру домохозяйства обратитесь в Белый дом и попросите референсную модель «BRM Services Code 001 Homeownership Promotion».

                                    И Вы тоже примеров публикации ЕА не видели? Какое этому объяснение?

                                    Ищите Reference Model (чего хотите, телеком операторов, банков и др.), в качестве примера, если вас интересуют только картинки, то посмотрите подраздел 1.3 тут Treasury Reference Model

                                    Как по-Вашему, кто целевой потребитель описания ЕА? Кроме самого архитектора, конечно.
                                    Руководитель предприятия должен понимать рисунок ЕА своего предприятия?

                                    Как думает участники BIANпросто так собрались? Они там просто прожигают деньги?
                                      –1
                                      Начало связи слева, конец справа. Читать нужно с «начала» в направлении «конца».

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

                                      Конечно, нет. Форма Вашего вопроса не располагает меня к ответу. И, по всей видимости, правильный развернутый ответ Вы знаете.

                                      Я теряюсь в догадках. Моя версия: пошли на спад продажи АРИС (это уже нарицательное, т.е. категория софта), давайте то же самое назовем иначе, «было BPM» – «стало ЕА», точнее новомодное ЕА, еще точнее хорошо забытое ЕА, — вспоминаем ZF и BSP!
                                      Те же картинки в такой же куче (по объему) нотаций (включая ЕРС) из АРИС, причем АРИС 20-летней давности, выглядели бы не хуже.
                                      Если Вам нужно другую архитектуру домохозяйства
                                      Хоть какую – нибудь, но полную.
                                      Вам же говорили, что нет исходной цели для чего и для кого нужно описать HA. Не выбраны точки зрения (view points).

                                      Для примера общежития, какие могут быть цели и view points? Уточните сами задачу: какие могут быть варианты ее постановки. Если просто сказать, что нужно описание ЕА – мало, то что нужно еще до-указать?

                                      Что такое «Заявка на архитектурную работу»? Примеров такой заявки полагаю — тоже нигде нет. Секретно.

                                      Какие в принципе могут быть цели составления описания ЕА (список)? Кто может быть в принципе потребителем ЕА (список)?

                                      Как думает участники BIAN просто так собрались?

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

                                      Они там просто прожигают деньги?

                                      Видимо, да. Прожигают. Только деньги банкиров. Может быть это всего лишь:
                                      Enterprise Voodoo, management fad, made in «Alchemy International»
                                      Не встречал ни одной не маркетинговой статьи в рунете по BIAN. Почему? Но слово красивое и употребляется часто и с «высокой значимостью».
                                      Вы ссылку на него дали, а практическое применение видели?

                                      В целом:
                                      Восхищен твоей самоотверженностью: к моей такой критической статье, — попробовать дать пример ЕА. Конкретных Описаний ЕА нигде не найти, а ты — раз — и что-то даже показал.
                                      Здорово. Молодец.
                            0
                            ;) интересный подход
                            правда…

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

                            зы
                            для bipiem,
                            pubs.opengroup.org/architecture/archimate3-doc
                              0
                              зачем вообще создавать описание архитектуры

                              Как вариант:
                              Если цель финансовой отчетности состоит в предоставлении достоверной информации о компании для принятия экономических решений,

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

                              Второй вариант ответа: «Описание ЕА нужно консалтерам, чтобы ее продать». Ценники на описание ЕА не публикуют, т.к.
                              «А гренка в нашем ресторане называется croûton. Это точно такой же поджаренный кусочек хлеба, но гренка не может стоить 8 долларов, а croûton — может»

                              Просто, может есть более простое название у этого загадочного ЕА, которое (другое название) всем понятно и все про него знают, только кому-то нужно продавать не гренки, а croûton?

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

                              Есть еще конкретные примеры описания ЕА?
                              Как Вы видите описание ЕА общежития?
                                0
                                Вы уверены, что представленные две схемы и есть полное «описание Архитектуры предприятия»? (пусть и типа общежитие) Собственно и на «гренку» не особо «тянет», не говоря уже про «крутон».

                                Вот этого я и ожидал, да.

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

                                  Не уверен. Но я это и не утверждал.

                                  Мои вопросы были наводящими.
                                  Зачем нужна конкретно та, представленная схема?
                                  Зачем нужно в общем описание архитектуры какого-то объекта?

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

                                  Ранее уже об этом упоминал. Для изменения объекта (общежития, предприятия, домохозяйства, города, etc). Если все обобщить, для принятия решений по изменению объекта и реализации этих решений.

                                  Почему я задал вопрос по представленной схеме.
                                  Потому что я не увидел в схеме важного, а важное определяется из «для чего эта схема».
                                  Ниже идет обсуждение, что это бизнес-срез. Ок. Зачем нам этот бизнес-срез?
                                  Начало схемs верное. Есть главный stakeholder. У него есть цели, правда она на схеме в виде драйвера. Увеличить доходность — это все-таки цель. А вот почему мы хотим увеличить доходность, это драйвер. Он может быть (и чаще всего таковым и является) внешним. (небольшое уточнение — увеличить доходность, это цель stakeholder'а, у описания архитектуры цель все та же, помогать менять организацию)
                                  От чего зависит наша доходность?
                                  Какое текущее состояние?
                                  Какое желаемое?
                                  Что нужно сделать чтобы из первого перейти во второе?
                                  Кто в этом задействован? Где нужно менять? И т.д.
                                  Да, это несколько срезов (views). И на срезах начинают пересекаться уровни (business layer, application layer, etc)
                                    0
                                    Вы задали много вопросов, и видимо должны быть ответы на них прямо в схеме? Где и чего не хватает? Что добавить на две предложенные выше и какие нужны дополнительные схемы? Или нужна табличка (ZF или другая)? Или бизнес-правила на каком-либо языке: структурированном или русском?
                                    Почему ссылок не привели (хоть с чем-то подобным)?
                                    Да, это несколько срезов (views). И на срезах начинают пересекаться уровни business layer, application layer, etc)

                                    Как в рамках данного примера Вы видите это пересечение?
                                    Какие нужны еще views? Желательно прямо показать эскиз или пример схемы.
                                    Кстати, классическое предприятие типа «общежитие» редко преследует цель «увеличить доходность».
                                      0
                                      Расшифровываю слова ggo:
                                      Нужно «легким движением руки крутануть колесо ADM» (использовал сарказм для понимания масштаба).
                                      Выполнить фазу «A. Vision»:
                                      • Установление архитектурного проекта (Establish the Architecture Project)
                                      • Выявление заинтересованных сторон, интересов и бизнес-требований
                                      • Закрепление и уточнение бизнес-целей, бизнес-драйверов и ограничений
                                      • Оценка бизнес-возможностей
                                      • Оценка готовности к трансформации бизнеса
                                      • Определение области (Define Scope)
                                      • Закрепление и уточнение Архитектурных принципов, включая бизнес-принципы
                                      • Разработка Архитектурного замысла
                                      • Определение ценности предложенной Целевой архитектуры и KPI
                                      • Выявление рисков трансформации бизнеса и способов по смягчению последствий
                                      • Разработка и утверждение Сметы на архитектурные работы

                                      А потом для КАЖДОЙ фазы B, C, D нужно сделать следующие шаги:
                                      • Выбор эталонных моделей (reference models), точек зрения (viewpoints) и инструментов (tools);
                                      • Разработка Описания базовой архитектуры (Baseline Architecture Description)
                                      • Разработка Описания целевой архитектуры (Target Architecture Description)
                                      • Анализ различий (Perform gap analysis);
                                      • Создание Архитектурного предложения с выбранными изменениями (Define candidate roadmap components);
                                      • Определение меры воздействия на Архитектурный ландшафт (Architecture Landscape);
                                      • Рассмотрение Архитектурного предложения заинтересованными сторонами (Conduct formal stakeholder review);
                                      • Завершение разработки архитектуры (Finalize the Architecture);
                                      • Создание документа Архитектурное решение (Architecture Definition Document).

                                      А что делать с фазой «Preliminary» не указано.
                                        0
                                        Забыл добавить ссылки на фазу «Preliminary». «не указано» — в том смысле, что в сообщении ggo не указано, поэтому не попало в расшифровку.
                                          0
                                          ссылки на фазу «Preliminary».

                                          Когда ТОГАФ говорит, что на вход «Предварительной фазы» (6.3.2 Не архитектурные входы) нужно подать Бизнес-стратегию и ИТ-стратегию, то это сразу вызывает ощущение: «Не взлетит». Если подать стратегии, которые были сделаны для компании внешними консалтерами, то вход 6.3.2 будет просто закупорен «маркетинговым мусором».

                                          Хорошо, эту фазу «Предварительную» для своей НА (или булочной) кто-то предложит? Прямо как там — в ТОГАФЕ — сказано.
                                          Кстати, мы же на русскоязычном форуме – лучше ссылки давать на переведенный ТОГАФ.
                                            0
                                            Вот уже интереснее.

                                            Выясняется, что даже для упрощенного объекта (общежитие) для одной цели (увеличить доходности) нужно с десяток схем (view), чтобы описать важные артефакты и их связи между собой, включая, кто, что, где, зачем, в рамках каких мероприятий меняет/меняется. Причем views рисуются не потому что кому-то нравится рисовать views, или нравится сам факт задокументированности, а рисуется ровно то, что касается зафиксированной цели — увеличения доходности.

                                            Переведенный TOGAF/Archimate не встречал.
                                              0
                                              views рисуются не потому что кому-то нравится рисовать views, или нравится сам факт задокументированности

                                              Что конкретно под Views понимаете? Любые схемы?

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

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

                                              Переведенный TOGAF/Archimate не встречал.

                                              Спецификация TOGAF, версия 9.1. Оглавление
                                              lnew39.ru/togaf
                                              Кому известны иные переводы TOGAF — добавляйте ссылки.

                                            0
                                            Зачем так «много букв»?
                                            Чаще говорят короче:
                                            1) as is (Baseline Architecture Description)
                                            2) to be (Target Architecture Description)
                                            3) roadmap (Define candidate roadmap components)

                                            А саму разработку тоже «минимизируют» (начать, посчитать «бабки» и закончить):
                                            Разработка Архитектурного замысла
                                            Разработка и утверждение Сметы на архитектурные работы
                                            Завершение разработки архитектуры (Finalize the Architecture);

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

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

                                            Как Вы видите практически этап:
                                            Выбор эталонных моделей (reference models), точек зрения (viewpoints) и инструментов (tools);
                                            Хоть для домохозяйства, хоть для любого другого предприятия? Желательно со ссылками на эти самые конкретные reference models и «кочки зрения».
                                            Гладко было на ТОГАФе, но забыли про овраги.
                                            0
                                            Нуу, тут никаких хитростей. Если все артефакты со всеми связями поместить на одну схему, будет большая паутина. Соответственно несколько схем (view), каждая со своим аспектом.

                                            Мы же уже выяснили, что нерафинированных примеров EA (публичных) нет.
                                            Поэтому и ссылок нет.

                                            Как выглядят пересечения layers можно посмотреть archimate examples. Да, это рафинад.
                                      0
                                      Два варианта:
                                      1. Описать текущее состояние.
                                      2. Описать переход от текущей к целевой архитектуре (например, случай отделения общежития от какого-нибудь предприятия с образованием хостела).

                                      Предусловие если брать варианта 1, но так чтобы можно было перейти в вариант 2:
                                      1. Общежитие принадлежит заводу (не важно какой).
                                      2. Формальная цель определена в уставе общежития: обеспечение сотрудников завода (приезжих и командируемых) условно-постоянным и временным жильем.
                                      3. Наполненность общежития сотрудниками недостаточная (большая часть мест не занята).
                                      4. Общежитие является убыточным подразделением завода.
                                      5. Руководство завода принимает решение преобразовать общежитие в хостел, который будет предоставлять места для сотрудников завода (с гарантированной квотой) и на открытом рынке гостиничных услуг.
                                      6. ОШС общежития: 1 заведующий, 3 вахтера (работают сутки через 2), 2 уборщицы, 1 завсклад (по совместительству зам. заведующей).
                                      7. Структура общежития: 4 блока, 1 склад, 2 подсобных помещения, 1 административное помещение.
                                      8. Структура блока: 8 комнат для жилья (4 2-х местных и 4 3-х местных), кухня, душ, 2 туалета, комната для умывания.
                                      9. У заведующий есть компьютер (для приема заявок с завода по почте) и телефон, на вахте тоже есть телефон.

                                      План работ по созданию текущей архитектуры (Baseline):
                                      1. Нужно доработать бизнес-архитектуру (БА, черновик есть выше в моем комментарии):
                                      1.1 Найти в интернете устав (там их полно) какого-нибудь общежития и другую полезную документацию. Четко зафиксировать, что работаем по этим документам.
                                      1.2 Определить основные бизнес-сервисы, функции, процессы. (Пока я вижу только один крупный сервис «Предоставление места в общежитие»).
                                      1.3 Определить заинтересованных сторон, драйверы. Есть формальная цель (указана в предусловии). Но цель предполагает ее достижение, поэтому в данном случае лучше использовать Course of Action.
                                      1.4 Детализировать основной бизнес-сервис в виде функций, сервисов и процессов.
                                      1.5 Определить обеспечивающие бизнес-функции, сервисы и процессы.
                                      1.6 Определить и сопоставить роли (взять из предусловия).
                                      1.7 Определить с какими бизнес-объектами работают бизнес-функции, сервисы и процессы.
                                      2. Разработать технологическую (ТА) и физическую архитектуру (ФА) (основу взять из предусловия)
                                      2.1 Схематично описать ФА: помещения, и основные материалы (в виде категорий). В ТА нужно добавить телефонную сеть и подключение к интернету.
                                      2.2 Сопоставить то, как ТА и ФА обеспечиваю выполнение бизнес-функций (сервисов, процессов) и соотносятся с бизнес-объектами.
                                      3. Доработать схему продукта «Место в общежитие» (черновик есть выше в моем комментарии).
                                      3.1 Добавить мотивационные элементы (драйверы, цели, требования).
                                      4. Архитектура приложений слабая: только почта.

                                      Итого в текущей архитектурe (Baseline) будет 2 точки зрения: Руководство и Житель. Заведующего включаем в Руководство. Соответственно 2 схемы и 2 пояснения:
                                      • Схема «Архитектура предоставления услуг общежития» (на одной схеме БА+АП+ТА+ФА)
                                      • Пояснения к схеме «Архитектуре предоставления услуг общежития»
                                      • Схема продукта «Место в общежитие»
                                      • Пояснения к схеме продукта «Место в общежитие»

                                      Никакой алхимии.
                                        0
                                        Вроде все подробно, но Теряюсь в догадках, «что делать».
                                        Остановились на первом варианте (Baseline) — как самом простом.

                                        У нас будет, я полагаю не схема «Архитектура» и не табличка (ZF), а уже целая книжка: «Описание ЕА». Верно?
                                        Нужно оглавление к книжке. А еще лучше хотя бы по паре предложений в каждый раздел.

                                        Названия к схемам вроде есть. В каких разделах они будут размещены?
                                        Достаточно всего двух этих схем?
                                        Схема «Архитектура предоставления услуг общежития» (на одной схеме БА+АП+ТА+ФА)

                                        По БА – фрагмент есть (первая схема), но как нарисовать остальное — не понятно. И это все на одну схему?
                                        на одной схеме БА+АП+ТА+ФА

                                        Это как? Все в кучу? Или просто четыре отдельные схемы на одном листе?
                                        будет 2 точки зрения: Руководство и Житель.

                                        Точка зрения архитектора или разработчика \ проектировщика не нужна?

                                        1.7 Определить с какими бизнес-объектами работают бизнес-функции, сервисы и процессы.

                                        И какие же это «бизнес-объекты»?

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое