Comment to 'SysMoLan Studio' by ailev
По опыту построения "Architecture as code" и ковыряния с Archi - технически все не так сложно.
У меня была задача заставить архитекторов следовать Hypothsis Driven Development. Рекомендация - моделировать изменения атомарно, используя Drivers,
Goals,
Stakeholders,
Outcomes,
Assessments,
Capabilities
с использованием Архимейта. (где влияние школы я думаю понятно). Концепция - архитектура и код нужно контролировать одинаково. Взяли Архи и разобрали xml формат в котором редактор хранит модели и viewpoints. С помощью (лома и azure) написали тесты к XML файлам и закрепили тесты стандартными средствами visual studio team service ( можно github или bitbucket) на проверку Pull Requestов. Таким образом получилось: архитектор или группа архитекторов забирает модель из git репозитория с git pull & git checkout. После обсуждения изменение документируется в архимейте и git push в отдельную ветку. В своей ветке архитектор может делать что хочет. Для перехода в следующую стадию нужно сделать Pull Request в основной репозиторий. При создании pull request c помощью webhooks срабатывают тесты и не дают пройти изменению если оно не соответствует атомарности (одна гипотиза за раз) или нет изменений в IT системе (архитектор ты работу не доделал). Если все тесты прошли PR можно Approve и тогда изменение входит в основную модель. В этот же момент можно задать webhook действие в DevOps стек - создать новый проект в jira для разработчиков и полную dev ops pipe line для продолжения изменения в релиз.
Итак, это было вступление. по поводу моделлера:
моделер нужно рассматривать как часть эко системы и надо демонстрировать ценность не только на уровне альф архитектуры/дизайна, но и далее по жизненному циклу - IMHO visual paradigm много теряет отказываясь интегрироваться с Jira/github.
Если оттолкнуться от github или bitbucket как репозиторий основного (основных) описание, и использовать родные инструменты git pull/git push/git commit + pull request для контроля конфигураций и разрешения конфликта то платформа для написания плагинов уже есть и множество кубиков:
* Например Archi модель можно выгрузить в Neo4J и использовать стандартные стредства визуализации и обработки данных графовой базы
* Опять же Archi можно выгрузить и в postres sql и прикрутить yED интерфейс через java/c#.
* через какой нибудь Javascript D3 написать github diff плагин для archi, это решит проблему коллаборативной работы.
А главное если модель живет как код и следует правилам обращения с кодом можно писать обработку модели и в Julia и в Java/Whatever с условием что токен действия и полное описание передаются через гитхаб.
View the entire thread this comment is a part of
У меня была задача заставить архитекторов следовать Hypothsis Driven Development. Рекомендация - моделировать изменения атомарно, используя Drivers,
Goals,
Stakeholders,
Outcomes,
Assessments,
Capabilities
с использованием Архимейта. (где влияние школы я думаю понятно). Концепция - архитектура и код нужно контролировать одинаково. Взяли Архи и разобрали xml формат в котором редактор хранит модели и viewpoints. С помощью (лома и azure) написали тесты к XML файлам и закрепили тесты стандартными средствами visual studio team service ( можно github или bitbucket) на проверку Pull Requestов. Таким образом получилось: архитектор или группа архитекторов забирает модель из git репозитория с git pull & git checkout. После обсуждения изменение документируется в архимейте и git push в отдельную ветку. В своей ветке архитектор может делать что хочет. Для перехода в следующую стадию нужно сделать Pull Request в основной репозиторий. При создании pull request c помощью webhooks срабатывают тесты и не дают пройти изменению если оно не соответствует атомарности (одна гипотиза за раз) или нет изменений в IT системе (архитектор ты работу не доделал). Если все тесты прошли PR можно Approve и тогда изменение входит в основную модель. В этот же момент можно задать webhook действие в DevOps стек - создать новый проект в jira для разработчиков и полную dev ops pipe line для продолжения изменения в релиз.
Итак, это было вступление. по поводу моделлера:
моделер нужно рассматривать как часть эко системы и надо демонстрировать ценность не только на уровне альф архитектуры/дизайна, но и далее по жизненному циклу - IMHO visual paradigm много теряет отказываясь интегрироваться с Jira/github.
Если оттолкнуться от github или bitbucket как репозиторий основного (основных) описание, и использовать родные инструменты git pull/git push/git commit + pull request для контроля конфигураций и разрешения конфликта то платформа для написания плагинов уже есть и множество кубиков:
* Например Archi модель можно выгрузить в Neo4J и использовать стандартные стредства визуализации и обработки данных графовой базы
* Опять же Archi можно выгрузить и в postres sql и прикрутить yED интерфейс через java/c#.
* через какой нибудь Javascript D3 написать github diff плагин для archi, это решит проблему коллаборативной работы.
А главное если модель живет как код и следует правилам обращения с кодом можно писать обработку модели и в Julia и в Java/Whatever с условием что токен действия и полное описание передаются через гитхаб.
View the entire thread this comment is a part of