#enterprise_architecture — Public Fediverse posts

Построение корпоративной архитектуры в ИТ-проектах на основе методологии TOGAF

Ошибочным будет пытаться рассмотреть разработку программного обеспечения с момента его реализации и внедрения. В литературных источниках по этому поводу говорится, что жизненный цикл программной системы начинается с момента понимания необходимости в ней и завершается ее заменой на аналогичные или более новые образцы [1-2]. Более того, проекту имплементации предшествуют активности предпроекта, включающие бизнес-кейс, проведение тендера и, наконец, заключение договора на внедрение, а завершается все задачами поддержки имплементированного решения и прекращением его применения. Анализ программного продукта через призму его жизненного цикла позволяет увязать бизнес-потребности организации и технические возможности их воплощения [3-4]. В проектах разработки высокосложного программного обеспечения жизненный цикл рассматривается с точки зрения репетиций внедрения, что позволяет понизить риск неуспешного продуктивного запуска. При этом вопросам построения масштабируемой, гибкой и отвечающей запросам бизнес-пользователей корпоративной ИТ-архитектуре в классических проектах имплементации программных систем уделяется меньшее внимание. Отдельное научное направление, отличающееся по содержанию от типовых подходов к разработке и внедрению программного обеспечения и обращающее должное внимание к ИТ-архитектуре, формализовалось в методологии TOGAF [5]. Жизненный цикл программного продукта с точки зрения принципов TOGAF сопровождается непрерывной и устойчивой взаимосвязью между бизнесом, разработкой приложений и ИТ-архитектурой для их развития, что является существенным преимуществом в конкурентной борьбе.

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

#togaf_10 #adm #корпоративная_архитектура #togaf #the_open_group #eabok #body_of_kbowledge #свод_знаний #библиотека_знаний_togaf #enterprise_architecture

Построение корпоративной архитектуры в ИТ-проектах, используя методологию TOGAF

Ошибочным будет пытаться рассмотреть разработку программного обеспечения с момента его реализации и внедрения. В литературных источниках по этому поводу говорится, что жизненный цикл программной системы начинается с момента понимания необходимости в ней и завершается ее заменой на аналогичные или более новые образцы [1-2]. Более того, проекту имплементации предшествуют активности предпроекта, включающие бизнес-кейс, проведение тендера и, наконец, заключение договора на внедрение, а завершается все задачами поддержки имплементированного решения и прекращением его применения. Анализ программного продукта через призму его жизненного цикла позволяет увязать бизнес-потребности организации и технические возможности их воплощения [3-4]. В проектах разработки высокосложного программного обеспечения жизненный цикл рассматривается с точки зрения репетиций внедрения, что позволяет понизить риск неуспешного продуктивного запуска. При этом вопросам построения масштабируемой, гибкой и отвечающей запросам бизнес-пользователей корпоративной ИТ-архитектуре в классических проектах имплементации программных систем уделяется меньшее внимание. Отдельное научное направление, отличающееся по содержанию от типовых подходов к разработке и внедрению программного обеспечения и обращающее должное внимание к ИТ-архитектуре, формализовалось в методологии TOGAF [5]. Жизненный цикл программного продукта с точки зрения принципов TOGAF сопровождается непрерывной и устойчивой взаимосвязью между бизнесом, разработкой приложений и ИТ-архитектурой для их развития, что является существенным преимуществом в конкурентной борьбе.

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

#togaf_10 #adm #корпоративная_архитектура #togaf #the_open_group #eabok #body_of_kbowledge #свод_знаний #библиотека_знаний_togaf #enterprise_architecture

Semantic BPM. Онтологическое моделирование верхнеуровневых процессов. VAD

Введение Представление моделей бизнес-процессов на основе онтологий (онтологическое моделирование) эквивалентно Semantic BPM . Введение в семантический BPM (Business Process Management) см. «Semantic BPM. Семантика и синтаксис бизнес-процессов» [semBPM24]. Если кратко, то можно провести аналогию: если классическая BPM система (BPMS: ARIS, бизнес-студия, fox-manager и т.п.) – это технологический аналог mediawiki (wikipedia), то Semantic BPM - это технологический аналог semantic mediaWiki (Wikidata), т.е. IF MediaWiki --> Semantic MediaWiki then BPM (ARIS, BPMS, EA) --> Semantic BPM Основной замысел (цель) семантического представления процессов (BPM, EA) не классическими BPM-системами, а семантическими (Linked Data) - такой же, как и у семантических wiki Одно из ключевых дополнений к wiki-гиперссылки (html) это указание не просто что «ОбъектА связан с ОбъектомБ» (т.е. просто «связано») и соответствующий кликабельный переход (wiki-ссылки, markdown syntax), а указание, что «ОбъектА связан с ОбъектомБ» такими-то типом отношения (впрочем, как и задание других свойств объекта через отношения). Изначально все BPMS (изначально называемые CASE-средствами) – семантические, т.к. их суть – это отношения между объектами, только в них семантика глубоко спрятана «под капотом» BPMS и нестандартная (собственная, проприетарная). Semantic BPM «поднимает» семантическую составляющую на поверхность (возможность работы с семантическим слоем) и использует стандартные сематические технологии Linked Data. В основе RDF (Resource Description Framework) – триплеты «субъект – отношение - объект» лежит ERD: Entity Relationship (ER) diagram . RDF \ ERD – это способ формализации знаний на основе атома знания – триплета. Вообще ER, subject, predicate, типы рассуждений и другие базовые элементы для работы со знаниями в СССР содержались в школьных учебниках [Логика54].

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

#семантика #онтология #aris #bpm #bpms #semantic_bpm #vad #rdf #enterprise_architecture

Semantic BPM. Семантика и синтаксис бизнес-процессов

Онтологический инжиниринг в области Управления бизнес-процессами (BPM). Семантический BPM (Business Process Management), впрочем, как и семантический ЕА (Enterprise Architecture), – это заимствование концепций (подходов к описанию и онтологизации) \ инструментов Linked Data к указанным направлениям (формализация процессов и архитектур предприятий). «Красная нить»: когда мы формализуем процессы - мы говорим об одном и том же, но на разных языках (нотациях), поэтому стандартизация Языка семантики, онтологических концептов BPM (EA) – важная, но еще недостаточно популяризированная составляющая развития BPM (следующий этап, ВРМ 3.0). Отделение («мух от котлет») семантики от синтаксиса позволит «рафинировать» понятийный (смысловой) анализ бизнес-процессов и при их аналитике оперировать базовыми (семантическими) концептами (образами). В Semantic BPM, как и в Semantic Web (семантическая паутина), смысл представленного процесса \ архитектуры понятен не только человеку, но и машинам и они могут его читать и обрабатывать. Эти смыслы, обычно передаваемые «человек – человек» на языке синтаксиса / графической грамматики через нотации VAD, EPC, BPMN, UML (плюс еще несколько десятков подобных вариантов \ форматов «обертывания», включая Дракон), исходно формализуются на языке семантики (стек Linked Data или аналогичный) и уже потом упаковываются в схемы с конкретной нотацией («пишутся» на языке какой-либо нотации). Для единого понимания смысловой составляющей схем применяется общая ВРМ-онтология, толковый словарь ВРМ.

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

#семантика #онтология #aris #bpm #Semantic_BPM #epc #bpms #semantic_web #enterprise_architecture #rdf