#моделирование_предметной_области — Public Fediverse posts

Архитектура ИТ решений. Часть 7. Графический язык моделирования ArchiMate. Начало

В прошлой части мы уже упоминали, что значимой проблемой при описании архитектуры предприятия является сведение разнородных артефактов разных уровней абстракции в единую картину мира. Аналогичные проблемы возникают в частности и на уровне моделирования. Как на одном полотне модели отображать и бизнес идеи, и сервисы прикладного слоя, и функциональность программных компонент, а еще “железо” на котором это все будет развернуто, и пробросить всевозможные связи между ними? Очевидно, что такие модели должны легко менять глубину детализации или выводить на более абстрактные представления. Все эти обстоятельства зачастую превращают моделирование в скопление красивых, но бесполезных диаграмм, которые ложатся "в стол", и в конечном итоге не позволяют использовать архитектуру как эффективный инструмент для принятия управленческих решений. Из этих размышлений, можно сделать вывод, что для качественного моделирования архитектуры предприятия нужен не просто инструмент моделирования, а поддержка в виде общепринятых стандартов моделирования архитектуры предприятия. Такое решение было предложено. ArchiMate в оригинале Architecture-Animate) — это открытый и независимый язык моделирования архитектуры предприятия для поддержки описания, анализа и визуализации архитектуры внутри и за пределами бизнес-процессов однозначным способом. Так же это технический стандарт от The Open Group, базирующийся на IEEE 1471. Он поддерживается различными разработчиками инструментов моделирования и консалтинговыми организациями.

https://habr.com/ru/articles/972736/

#архитектура_приложений #архитектура_по #архитектура_систем #слои_архитектуры #итинфраструктура #итархитектура #итиндустрия #моделирование_систем #моделирование_решений #моделирование_предметной_области

Архитектура ИТ решений. Часть 7. Графический язык моделирования ArchiMate. Начало

В прошлой части мы уже упоминали, что значимой проблемой при описании архитектуры предприятия является сведение разнородных артефактов разных уровней абстракции в единую картину мира. Аналогичные проблемы возникают в частности и на уровне моделирования. Как на одном полотне модели отображать и бизнес идеи, и сервисы прикладного слоя, и функциональность программных компонент, а еще “железо” на котором это все будет развернуто, и пробросить всевозможные связи между ними? Очевидно, что такие модели должны легко менять глубину детализации или выводить на более абстрактные представления. Все эти обстоятельства зачастую превращают моделирование в скопление красивых, но бесполезных диаграмм, которые ложатся "в стол", и в конечном итоге не позволяют использовать архитектуру как эффективный инструмент для принятия управленческих решений. Из этих размышлений, можно сделать вывод, что для качественного моделирования архитектуры предприятия нужен не просто инструмент моделирования, а поддержка в виде общепринятых стандартов моделирования архитектуры предприятия. Такое решение было предложено. ArchiMate в оригинале Architecture-Animate) — это открытый и независимый язык моделирования архитектуры предприятия для поддержки описания, анализа и визуализации архитектуры внутри и за пределами бизнес-процессов однозначным способом. Так же это технический стандарт от The Open Group, базирующийся на IEEE 1471. Он поддерживается различными разработчиками инструментов моделирования и консалтинговыми организациями.

https://habr.com/ru/articles/972736/

#архитектура_приложений #архитектура_по #архитектура_систем #слои_архитектуры #итинфраструктура #итархитектура #итиндустрия #моделирование_систем #моделирование_решений #моделирование_предметной_области

Архитектура ИТ решений. Часть 7. Графический язык моделирования ArchiMate. Начало

В прошлой части мы уже упоминали, что значимой проблемой при описании архитектуры предприятия является сведение разнородных артефактов разных уровней абстракции в единую картину мира. Аналогичные проблемы возникают в частности и на уровне моделирования. Как на одном полотне модели отображать и бизнес идеи, и сервисы прикладного слоя, и функциональность программных компонент, а еще “железо” на котором это все будет развернуто, и пробросить всевозможные связи между ними? Очевидно, что такие модели должны легко менять глубину детализации или выводить на более абстрактные представления. Все эти обстоятельства зачастую превращают моделирование в скопление красивых, но бесполезных диаграмм, которые ложатся "в стол", и в конечном итоге не позволяют использовать архитектуру как эффективный инструмент для принятия управленческих решений. Из этих размышлений, можно сделать вывод, что для качественного моделирования архитектуры предприятия нужен не просто инструмент моделирования, а поддержка в виде общепринятых стандартов моделирования архитектуры предприятия. Такое решение было предложено. ArchiMate в оригинале Architecture-Animate) — это открытый и независимый язык моделирования архитектуры предприятия для поддержки описания, анализа и визуализации архитектуры внутри и за пределами бизнес-процессов однозначным способом. Так же это технический стандарт от The Open Group, базирующийся на IEEE 1471. Он поддерживается различными разработчиками инструментов моделирования и консалтинговыми организациями.

https://habr.com/ru/articles/972736/

#архитектура_приложений #архитектура_по #архитектура_систем #слои_архитектуры #итинфраструктура #итархитектура #итиндустрия #моделирование_систем #моделирование_решений #моделирование_предметной_области

Архитектура ИТ решений. Часть 7. Графический язык моделирования ArchiMate. Начало

В прошлой части мы уже упоминали, что значимой проблемой при описании архитектуры предприятия является сведение разнородных артефактов разных уровней абстракции в единую картину мира. Аналогичные проблемы возникают в частности и на уровне моделирования. Как на одном полотне модели отображать и бизнес идеи, и сервисы прикладного слоя, и функциональность программных компонент, а еще “железо” на котором это все будет развернуто, и пробросить всевозможные связи между ними? Очевидно, что такие модели должны легко менять глубину детализации или выводить на более абстрактные представления. Все эти обстоятельства зачастую превращают моделирование в скопление красивых, но бесполезных диаграмм, которые ложатся "в стол", и в конечном итоге не позволяют использовать архитектуру как эффективный инструмент для принятия управленческих решений. Из этих размышлений, можно сделать вывод, что для качественного моделирования архитектуры предприятия нужен не просто инструмент моделирования, а поддержка в виде общепринятых стандартов моделирования архитектуры предприятия. Такое решение было предложено. ArchiMate в оригинале Architecture-Animate) — это открытый и независимый язык моделирования архитектуры предприятия для поддержки описания, анализа и визуализации архитектуры внутри и за пределами бизнес-процессов однозначным способом. Так же это технический стандарт от The Open Group, базирующийся на IEEE 1471. Он поддерживается различными разработчиками инструментов моделирования и консалтинговыми организациями.

https://habr.com/ru/articles/972736/

#архитектура_приложений #архитектура_по #архитектура_систем #слои_архитектуры #итинфраструктура #итархитектура #итиндустрия #моделирование_систем #моделирование_решений #моделирование_предметной_области

ArchiMate на практике: архитектурное моделирование бизнес-процесса ФЗ «О персональных данных»

ArchiMate, являясь языком проектирования архитектуры, предоставляет чёткую систему взаимосвязей между объектами. Эта система задаёт возможные варианты отношений для конкретной ситуации и контекста. Учитывая универсальность языка, это огромное преимущество — с его помощью можно описать как бизнес-архитектуру, так и системную, и технологическую. В данной статье я приведу пример моделирования в нотации ArchiMate для ситуации, когда необходимо смоделировать бизнес-процесс сложной и противоречивой предметной области. Такая задача часто встречается при автоматизации процессов государственных органов и организаций, работающих в строгих законодательных рамках. Представьте : вам поручили спроектировать систему, обрабатывающую персональные данные. Требования размазаны по пулу статей НПА, а за ошибку грозят миллионные штрафы. Как структурировать эту сложную область и убедиться, что вы ничего не упустили? В этой статье я на примере положений ФЗ «О персональных данных» (далее по тексту – ФЗ) покажу, как язык ArchiMate помогает превратить юридический текст в четкую архитектурную схему. Такой подход помогает выявить пробелы в требованиях, наглядно согласовать их с заказчиком и заложить основу для проектирования ИТ-решений. Узнать больше

https://habr.com/ru/articles/971012/

#методология #корпоративная_архитектура #бизнеспроцессы #бизнесанализ #бизнесаналитик #бизнестребования #управление_требованиями #archimate #моделирование_предметной_области #проектирование_систем

Архитектура ИТ решений. Часть 6. Подходы к построению Архитектуры

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

https://habr.com/ru/articles/967520/

#архитектура_приложений #архитектура_по #архитектура_систем #слои_архитектуры #итинфраструктура #итиндустрия #моделирование_решений #моделирование_предметной_области #предприятие #структура_компании

Архитектура ИТ решений. Часть 6. Подходы к построению Архитектуры

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

https://habr.com/ru/articles/967520/

#архитектура_приложений #архитектура_по #архитектура_систем #слои_архитектуры #итинфраструктура #итиндустрия #моделирование_решений #моделирование_предметной_области #предприятие #структура_компании

Архитектура ИТ решений. Часть 6. Подходы к построению Архитектуры

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

https://habr.com/ru/articles/967520/

#архитектура_приложений #архитектура_по #архитектура_систем #слои_архитектуры #итинфраструктура #итиндустрия #моделирование_решений #моделирование_предметной_области #предприятие #структура_компании

Архитектура ИТ решений. Часть 6. Подходы к построению Архитектуры

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

https://habr.com/ru/articles/967520/

#архитектура_приложений #архитектура_по #архитектура_систем #слои_архитектуры #итинфраструктура #итиндустрия #моделирование_решений #моделирование_предметной_области #предприятие #структура_компании

Почему управление ИТ-инфраструктурой становится только сложнее и что с этим делать?

Проблему усложнения инфраструктуры отмечают все, кто ей занимается в разных ролях, от проектирования архитектуры до имплементации и ежедневной эксплуатации. Инженеры, архитекторы и разработчики признают, что управление инфраструктурой сегодня уже не тривиальная задача. Создавая open-source проект Foliage , мы исходили именно из тезиса о том, что «современная инфра – это сложно». Но обо всём по порядку. С трибун конференций ИТ-директора больших интернет-бизнесов говорили об успехах внедрения инструментов или практик, а в кулуарах – о том, что каждое новое внедрение только добавляет им тревоги. Растущее количество инструментов только усиливало ощущение потери контроля. Стало отчётливо видно: беспокойство растёт даже у тех, кто «всё сделал правильно». Сегодня инфраструктура «болит» у всех крупных организаций независимо от того, есть у них высокие нагрузки или нет. Оказывается, недостаточно просто собрать требования, закупить под них оборудование, лицензии на программное обеспечение и нанять людей. Но почему? Мы с командой Foliage решили в этом разобраться и собрали свои выводы в эту статью.

https://habr.com/ru/companies/foliage/articles/963248/

#цифровые_двойники #моделирование_предметной_области #итинфраструктура #цифровые_модели #observability #monitoring #мониторинг #digital_twins

Почему управление ИТ-инфраструктурой становится только сложнее и что с этим делать?

Проблему усложнения инфраструктуры отмечают все, кто ей занимается в разных ролях, от проектирования архитектуры до имплементации и ежедневной эксплуатации. Инженеры, архитекторы и разработчики признают, что управление инфраструктурой сегодня уже не тривиальная задача. Создавая open-source проект Foliage , мы исходили именно из тезиса о том, что «современная инфра – это сложно». Но обо всём по порядку. С трибун конференций ИТ-директора больших интернет-бизнесов говорили об успехах внедрения инструментов или практик, а в кулуарах – о том, что каждое новое внедрение только добавляет им тревоги. Растущее количество инструментов только усиливало ощущение потери контроля. Стало отчётливо видно: беспокойство растёт даже у тех, кто «всё сделал правильно». Сегодня инфраструктура «болит» у всех крупных организаций независимо от того, есть у них высокие нагрузки или нет. Оказывается, недостаточно просто собрать требования, закупить под них оборудование, лицензии на программное обеспечение и нанять людей. Но почему? Мы с командой Foliage решили в этом разобраться и собрали свои выводы в эту статью.

https://habr.com/ru/companies/foliage/articles/963248/

#цифровые_двойники #моделирование_предметной_области #итинфраструктура #цифровые_модели #observability #monitoring #мониторинг #digital_twins

Почему управление ИТ-инфраструктурой становится только сложнее и что с этим делать?

Проблему усложнения инфраструктуры отмечают все, кто ей занимается в разных ролях, от проектирования архитектуры до имплементации и ежедневной эксплуатации. Инженеры, архитекторы и разработчики признают, что управление инфраструктурой сегодня уже не тривиальная задача. Создавая open-source проект Foliage , мы исходили именно из тезиса о том, что «современная инфра – это сложно». Но обо всём по порядку. С трибун конференций ИТ-директора больших интернет-бизнесов говорили об успехах внедрения инструментов или практик, а в кулуарах – о том, что каждое новое внедрение только добавляет им тревоги. Растущее количество инструментов только усиливало ощущение потери контроля. Стало отчётливо видно: беспокойство растёт даже у тех, кто «всё сделал правильно». Сегодня инфраструктура «болит» у всех крупных организаций независимо от того, есть у них высокие нагрузки или нет. Оказывается, недостаточно просто собрать требования, закупить под них оборудование, лицензии на программное обеспечение и нанять людей. Но почему? Мы с командой Foliage решили в этом разобраться и собрали свои выводы в эту статью.

https://habr.com/ru/companies/foliage/articles/963248/

#цифровые_двойники #моделирование_предметной_области #итинфраструктура #цифровые_модели #observability #monitoring #мониторинг #digital_twins

Почему управление ИТ-инфраструктурой становится только сложнее и что с этим делать?

Проблему усложнения инфраструктуры отмечают все, кто ей занимается в разных ролях, от проектирования архитектуры до имплементации и ежедневной эксплуатации. Инженеры, архитекторы и разработчики признают, что управление инфраструктурой сегодня уже не тривиальная задача. Создавая open-source проект Foliage , мы исходили именно из тезиса о том, что «современная инфра – это сложно». Но обо всём по порядку. С трибун конференций ИТ-директора больших интернет-бизнесов говорили об успехах внедрения инструментов или практик, а в кулуарах – о том, что каждое новое внедрение только добавляет им тревоги. Растущее количество инструментов только усиливало ощущение потери контроля. Стало отчётливо видно: беспокойство растёт даже у тех, кто «всё сделал правильно». Сегодня инфраструктура «болит» у всех крупных организаций независимо от того, есть у них высокие нагрузки или нет. Оказывается, недостаточно просто собрать требования, закупить под них оборудование, лицензии на программное обеспечение и нанять людей. Но почему? Мы с командой Foliage решили в этом разобраться и собрали свои выводы в эту статью.

https://habr.com/ru/companies/foliage/articles/963248/

#цифровые_двойники #моделирование_предметной_области #итинфраструктура #цифровые_модели #observability #monitoring #мониторинг #digital_twins

Проектирование Информационных систем. Часть 8. Разработка логической структуры данных. 8.2. Шаблонный подход

В 1950 году математик по имени Клод Шеннон опубликовал в журнале статью «Как запрограммировать компьютер для игры в шахматы». В этой статье он подсчитал, что количество комбинаций в шахматах будет равно 10 120 . Это на самом деле превосходит количество атомов в известной Вселенной, которое оценивается от 10 78 до 10 82 атомов. Но среднестатистическому шахматисту для успешного старта не обязательно изучать все существующие варианты начала игры, а достаточно выбрать несколько популярных дебютов за каждый цвет. По факту это использование формализованных шаблонов успешных тактических позиций для достижения желаемых результатов. Аналогично шахматным, успешные шаблоны используют и в ИТ. Для того, чтобы, при решении однотипные задачи проектирования не изобретать каждый раз велосипед, принято использовать паттерны проектирования. Давайте рассмотрим некоторые из них, применительно к моделированию хранилищ данных. Приспособленец (Flyweight) - структурный паттерн проектирования, который нужен для эффективной работы с большим количеством мелких объектов. Основная идея: разделить общее состояние объектов и вынести его в отдельное место , чтобы не плодить кучу дубликатов данных и экономить место. При этом объект, представляет себя как уникальный экземпляр в разных местах программы, но фактически не являющийся таковым.

https://habr.com/ru/articles/918450/

#проектирование_систем #проектирование_по #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #паттерны_проектирования #моделирование_данных #моделирование_предметной_области

Проектирование Информационных систем. Часть 8. Разработка логической структуры данных. 8.2. Шаблонный подход

В 1950 году математик по имени Клод Шеннон опубликовал в журнале статью «Как запрограммировать компьютер для игры в шахматы». В этой статье он подсчитал, что количество комбинаций в шахматах будет равно 10 120 . Это на самом деле превосходит количество атомов в известной Вселенной, которое оценивается от 10 78 до 10 82 атомов. Но среднестатистическому шахматисту для успешного старта не обязательно изучать все существующие варианты начала игры, а достаточно выбрать несколько популярных дебютов за каждый цвет. По факту это использование формализованных шаблонов успешных тактических позиций для достижения желаемых результатов. Аналогично шахматным, успешные шаблоны используют и в ИТ. Для того, чтобы, при решении однотипные задачи проектирования не изобретать каждый раз велосипед, принято использовать паттерны проектирования. Давайте рассмотрим некоторые из них, применительно к моделированию хранилищ данных. Приспособленец (Flyweight) - структурный паттерн проектирования, который нужен для эффективной работы с большим количеством мелких объектов. Основная идея: разделить общее состояние объектов и вынести его в отдельное место , чтобы не плодить кучу дубликатов данных и экономить место. При этом объект, представляет себя как уникальный экземпляр в разных местах программы, но фактически не являющийся таковым.

https://habr.com/ru/articles/918450/

#проектирование_систем #проектирование_по #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #паттерны_проектирования #моделирование_данных #моделирование_предметной_области

Проектирование Информационных систем. Часть 8. Разработка логической структуры данных. 8.2. Шаблонный подход

В 1950 году математик по имени Клод Шеннон опубликовал в журнале статью «Как запрограммировать компьютер для игры в шахматы». В этой статье он подсчитал, что количество комбинаций в шахматах будет равно 10 120 . Это на самом деле превосходит количество атомов в известной Вселенной, которое оценивается от 10 78 до 10 82 атомов. Но среднестатистическому шахматисту для успешного старта не обязательно изучать все существующие варианты начала игры, а достаточно выбрать несколько популярных дебютов за каждый цвет. По факту это использование формализованных шаблонов успешных тактических позиций для достижения желаемых результатов. Аналогично шахматным, успешные шаблоны используют и в ИТ. Для того, чтобы, при решении однотипные задачи проектирования не изобретать каждый раз велосипед, принято использовать паттерны проектирования. Давайте рассмотрим некоторые из них, применительно к моделированию хранилищ данных. Приспособленец (Flyweight) - структурный паттерн проектирования, который нужен для эффективной работы с большим количеством мелких объектов. Основная идея: разделить общее состояние объектов и вынести его в отдельное место , чтобы не плодить кучу дубликатов данных и экономить место. При этом объект, представляет себя как уникальный экземпляр в разных местах программы, но фактически не являющийся таковым.

https://habr.com/ru/articles/918450/

#проектирование_систем #проектирование_по #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #паттерны_проектирования #моделирование_данных #моделирование_предметной_области

Проектирование Информационных систем. Часть 8. Разработка логической структуры данных. 8.2. Шаблонный подход

В 1950 году математик по имени Клод Шеннон опубликовал в журнале статью «Как запрограммировать компьютер для игры в шахматы». В этой статье он подсчитал, что количество комбинаций в шахматах будет равно 10 120 . Это на самом деле превосходит количество атомов в известной Вселенной, которое оценивается от 10 78 до 10 82 атомов. Но среднестатистическому шахматисту для успешного старта не обязательно изучать все существующие варианты начала игры, а достаточно выбрать несколько популярных дебютов за каждый цвет. По факту это использование формализованных шаблонов успешных тактических позиций для достижения желаемых результатов. Аналогично шахматным, успешные шаблоны используют и в ИТ. Для того, чтобы, при решении однотипные задачи проектирования не изобретать каждый раз велосипед, принято использовать паттерны проектирования. Давайте рассмотрим некоторые из них, применительно к моделированию хранилищ данных. Приспособленец (Flyweight) - структурный паттерн проектирования, который нужен для эффективной работы с большим количеством мелких объектов. Основная идея: разделить общее состояние объектов и вынести его в отдельное место , чтобы не плодить кучу дубликатов данных и экономить место. При этом объект, представляет себя как уникальный экземпляр в разных местах программы, но фактически не являющийся таковым.

https://habr.com/ru/articles/918450/

#проектирование_систем #проектирование_по #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #паттерны_проектирования #моделирование_данных #моделирование_предметной_области