AL
А потом ещё раз серьёзно подумать над тем почему именно архитектором.
Size: a a a
2021 January 12
DB
Я хочу развиваться по профессии и выйти в Архитекторы
AL
Я хочу развиваться по профессии и выйти в Архитекторы
Денег хочется больше? Ответственности? Результатов? Экспертизы в технике?
Развитие - это очень общо. Смысл нужно конкретизировать.
Развитие - это очень общо. Смысл нужно конкретизировать.
AL
Выйти в архитекторы - это не самоцель. В отрыве от реальности смысла в лычке - ноль.
DB
Хочу разбираться в технологиях и их решениях. Так же решать сложные проблемы компаний. Именно в Архитектуре - ну потому что нравится.
АЛ
И тут еще такая штука, каким архитектором? DBA, system, solution, enterprise...
DB
Ну я еще не боюсь брать ответственность на себя\
DB
вот тут есть куда разгуляться. Я на данный момент Java web developer
A
Выйти в архитекторы - это не самоцель. В отрыве от реальности смысла в лычке - ноль.
Ага и поэтому некоторые люди никогда ни в коем случае не будут общаться с кем то ниже VP, а с совещания, на котором есть аналитик - просто вставать и уходить.
АЛ
в любом случае читайте/смотрите лекции по Системной инженерии, почитайте TOGAF, разберитесь с ArchiMate (как минимум начните свою работу проектировать и документировать при помощи бесплатного Archi). А дальше смотрите что вам больше нравиться и качайте соотвествующие скилы. Корпоративная архитекутра это отдельный пласт и там полезно, но не обязательно быть программистом, архитектор решений или системный архитектор - тут будет большим плюсом ваши навыки из разработки
A
Культ лычки (должности, ранга, etc) пока еще широко распространен.
АЛ
в TOGAF, кстати, есть перечень компетенций и их мапинг на различные роли, в том числе и на архитекторов
AL
Ага и поэтому некоторые люди никогда ни в коем случае не будут общаться с кем то ниже VP, а с совещания, на котором есть аналитик - просто вставать и уходить.
Не понял тезиса. Но если про необходимость поддержания в рабочем коллективе соответствия уровней полномочий и ответственности, то да. Если про цинизм и самомнение - ну бывает. Обычно не долго)
DB
благодарю за советы
F
в TOGAF, кстати, есть перечень компетенций и их мапинг на различные роли, в том числе и на архитекторов
Может уже o-aaf, togaf плато прошел, начинается спад.
АЛ
может. В нем много всего собрано интересного, что при правильном приготовлении может дать ощутимую практическую пользу. А весь ADM прямо вот как в TOGAF прописано... Я за весь свой опыт не встречал :)
P
Может уже o-aaf, togaf плато прошел, начинается спад.
O-AAF интересный, познавательный, и я бы сказал, сработанный на опережение. Но учиться по нему сложновато - лучше уже имея опыт в корпоративной архитектуре.
TOGAF детально до артефактов даже не знаю кто применяет в России и Европе.
Но основу по нему надо закладывать (имхо): ADM, building blocks...
TOGAF детально до артефактов даже не знаю кто применяет в России и Европе.
Но основу по нему надо закладывать (имхо): ADM, building blocks...
2021 January 13
М
Леонардо Пизанский.
М
А какие есть материалы по O-AAF или TOGAF чтобы научиться моделировать архитектуру, например, в Archi?
Немного поясню свою проблему.
У меня сейчас стоит соответствующая задача по описанию архитектуры as is. Ближайшие цели: показать компоненты, из которых состоит система; взаимодействие между ними; технологии, на которых они основаны. Всё это нужно для того, чтобы новым специалистам (да и старым тоже) было проще понять, как что где устроено и работает. Типа такое общее наглядное описание всей системы в целом и в будущем с возможностями декомпозиции отдельных элементов системы. Также в будущем данная модель должна будет использоваться для оптимизации и развития системы.
Archimate я изучал в основном по статьям Алиева, но он рассказывает слишком пространно, чтобы можно было сразу взять и составить хорошую, работающую модель. Например, я так и не понял: с чего лучше начать? Где показывать процессы, а где функции? Где компоненты, а где продукты? Где сервисы, а где интерфейсы? И т.д. Вообще, как я понял, archimate - такой язык, в котором одна сущность с одним названием может одновременно являться и компонентом и сервисом и продуктом и ещё много чем. То есть без специального продуманного подхода к моделированию, просто набрасыванием известных объектов и связей между ними (как, например, можно в UML) вряд ли получиться сделать что-то толковое. У меня всегда получается какой-то хаос, который потом приходится хорошенько чистить от лишнего и даже после этого результат получается далёк от идеала.
Немного поясню свою проблему.
У меня сейчас стоит соответствующая задача по описанию архитектуры as is. Ближайшие цели: показать компоненты, из которых состоит система; взаимодействие между ними; технологии, на которых они основаны. Всё это нужно для того, чтобы новым специалистам (да и старым тоже) было проще понять, как что где устроено и работает. Типа такое общее наглядное описание всей системы в целом и в будущем с возможностями декомпозиции отдельных элементов системы. Также в будущем данная модель должна будет использоваться для оптимизации и развития системы.
Archimate я изучал в основном по статьям Алиева, но он рассказывает слишком пространно, чтобы можно было сразу взять и составить хорошую, работающую модель. Например, я так и не понял: с чего лучше начать? Где показывать процессы, а где функции? Где компоненты, а где продукты? Где сервисы, а где интерфейсы? И т.д. Вообще, как я понял, archimate - такой язык, в котором одна сущность с одним названием может одновременно являться и компонентом и сервисом и продуктом и ещё много чем. То есть без специального продуманного подхода к моделированию, просто набрасыванием известных объектов и связей между ними (как, например, можно в UML) вряд ли получиться сделать что-то толковое. У меня всегда получается какой-то хаос, который потом приходится хорошенько чистить от лишнего и даже после этого результат получается далёк от идеала.
НП
А какие есть материалы по O-AAF или TOGAF чтобы научиться моделировать архитектуру, например, в Archi?
Немного поясню свою проблему.
У меня сейчас стоит соответствующая задача по описанию архитектуры as is. Ближайшие цели: показать компоненты, из которых состоит система; взаимодействие между ними; технологии, на которых они основаны. Всё это нужно для того, чтобы новым специалистам (да и старым тоже) было проще понять, как что где устроено и работает. Типа такое общее наглядное описание всей системы в целом и в будущем с возможностями декомпозиции отдельных элементов системы. Также в будущем данная модель должна будет использоваться для оптимизации и развития системы.
Archimate я изучал в основном по статьям Алиева, но он рассказывает слишком пространно, чтобы можно было сразу взять и составить хорошую, работающую модель. Например, я так и не понял: с чего лучше начать? Где показывать процессы, а где функции? Где компоненты, а где продукты? Где сервисы, а где интерфейсы? И т.д. Вообще, как я понял, archimate - такой язык, в котором одна сущность с одним названием может одновременно являться и компонентом и сервисом и продуктом и ещё много чем. То есть без специального продуманного подхода к моделированию, просто набрасыванием известных объектов и связей между ними (как, например, можно в UML) вряд ли получиться сделать что-то толковое. У меня всегда получается какой-то хаос, который потом приходится хорошенько чистить от лишнего и даже после этого результат получается далёк от идеала.
Немного поясню свою проблему.
У меня сейчас стоит соответствующая задача по описанию архитектуры as is. Ближайшие цели: показать компоненты, из которых состоит система; взаимодействие между ними; технологии, на которых они основаны. Всё это нужно для того, чтобы новым специалистам (да и старым тоже) было проще понять, как что где устроено и работает. Типа такое общее наглядное описание всей системы в целом и в будущем с возможностями декомпозиции отдельных элементов системы. Также в будущем данная модель должна будет использоваться для оптимизации и развития системы.
Archimate я изучал в основном по статьям Алиева, но он рассказывает слишком пространно, чтобы можно было сразу взять и составить хорошую, работающую модель. Например, я так и не понял: с чего лучше начать? Где показывать процессы, а где функции? Где компоненты, а где продукты? Где сервисы, а где интерфейсы? И т.д. Вообще, как я понял, archimate - такой язык, в котором одна сущность с одним названием может одновременно являться и компонентом и сервисом и продуктом и ещё много чем. То есть без специального продуманного подхода к моделированию, просто набрасыванием известных объектов и связей между ними (как, например, можно в UML) вряд ли получиться сделать что-то толковое. У меня всегда получается какой-то хаос, который потом приходится хорошенько чистить от лишнего и даже после этого результат получается далёк от идеала.
есть вот такой материал. я по нему изучаю
https://youtube.com/playlist?list=PLkAK0ZVQdawkuflYvc8gGTQhN8OOxoHTi
https://youtube.com/playlist?list=PLkAK0ZVQdawkuflYvc8gGTQhN8OOxoHTi