Size: a a a

2021 May 12

E

EG.spb in SPb CoA
источник

E

EG.spb in SPb CoA
источник

E

EG.spb in SPb CoA
источник

E

EG.spb in SPb CoA
источник

E

EG.spb in SPb CoA
из свободного доступа
источник

NM

Nikita M in SPb CoA
о, спс!
источник

NM

Nikita M in SPb CoA
Нашёл вот - https://archimatetool.gitbook.io/
И вот маркетинговая шпаргалка за мою корп.почту
источник

VK

Vladislav Kotov in SPb CoA
Что-то уровней для последней версии маловато
источник

ОИ

Олег Игонин... in SPb CoA
источник

ОИ

Олег Игонин... in SPb CoA
По кукабуке, понимая, зачем тебе архимейт, можно всё быстро освоить.
источник

ОИ

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

ОИ

Олег Игонин... in SPb CoA
Т.е. он  должен покрывать всю основную реализацию бизнес-процессов в компании.
источник

ОИ

Олег Игонин... in SPb CoA
Тогда можно увидеть в понятной (нет) схеме как работает процесс, с какими целями, как он попадает в ит систему, какие сервисы отвечают за его работу на стороне ит, что в результате производит.
источник

ОИ

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

И по сути у тебя всё время под рукой схема как работает твой домен.
Когда ты видишь несостыковки со схемой архи, то можно задать риторический вопрос "так б*..." и идти трясти тех, кто решение протащил без твоего согласования.
источник

ОИ

Олег Игонин... in SPb CoA
Из полезного я вижу пока что только этот подход.

Также можно скармливать домен в архмейте своему Enterprice Architect, а тот уже будет сидеть с ним аки генерал с картой и мыслить, куда рулить кораблём.
источник

ОИ

Олег Игонин... in SPb CoA
В конечном итоге самый крутой результат - это возможность быстрого и понятного принятия бизнес-решения на уровне EA.
источник

ОИ

Олег Игонин... in SPb CoA
Короче тема. Чтобы проще всё понять, то стоит представлять разработку как военное подразделение:

- генерал - Enterprise architect: заведует всем фронтом, определяет участки наступления, руководит всеми войсками, на самом верхнем уровне деления. Для нас это бизнес-домен.

- адъютанты - Solution architect: постоянно передают обобщённые данные с фронта - положение войск, численность, погоду, запасы продовольствия и амуниции, а также приводят к исполнению приказы EA на местах, выдавая указания генерала и проверяя их исполнение (работа в соответствии с архитектурной концепцией от EA, определение технологий, принятие верхнеуровневых решений, проверка исполнения (арх. ревью), сбор статистики и описание верхнеуровневой реализации).

- наводчики - BA/SA: работают в поле, наводят бойцов на цели, работают в отрядах по 4-7 человек. Иногда могут  наводить сразу несколько отрядов. Отдают детальные отчёты адъютантам.

- пехота - разработчики, делает дело.

- челы с биноклями, подтверждающие уничтожение целей и всё такое - тестировщики.

- комиссары - пм"ы.

- полковники - System architect: следят за вверенными им частями. Делятся фронтовики, тыловики, и тд (определяют принципы построения систем, сетей. Контролируют. Определяют технологии).
источник

Y

YA in SPb CoA
Интересное заявление для тех, у кого есть военный опыт😀
источник

ОИ

Олег Игонин... in SPb CoA
0 опыта)
источник

ОИ

Олег Игонин... in SPb CoA
Просто часто задают вопрос, кто такой EA и что он забыл в компании
источник